supplierdeeply
« previous next »
Pages: 1 2 3 4 [5] 6 7 8 9 10 11   Go Down

Improving CHDK ND filter support

  • 108 Replies
  • 33153 Views
*

Offline reyalp

  • ******
  • 11592
Re: Improving CHDK ND filter support
« Reply #40 on: 24 / December / 2017, 16:59:12 »
Advertisements
Quote from: srsa_4c on 24 / December / 2017, 10:17:18
See attached pictures, most spots are there on both shots (F8, full zoom, focus on infinite, "ND" in & out).
Yeah, the fact the spots get sharper with "ND" in makes it pretty clear the aperture is changing.

I think it's safe to conclude the "hidden" ND is actually just a funny way to control the aperture, and these cameras do not actually have a ND filter.

My feeling is we should undefine CAM_HAS_ND_FILTER on these cams, but I'm willing to hear arguments against.

The sig finders can probably suggest the correct value of CAM_HAS_ND_FILTER based on presence of ND task.

As an aside, GetUsableMinAv may be useful for script and overrides. We can't use use it to limit the override input (since it depends on zoom, which might change after setting override) but we could perhaps show it in the state displays, e.g. red when the override is beyond the valid range for current zoom.
« Last Edit: 25 / December / 2017, 22:29:11 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: Improving CHDK ND filter support
« Reply #41 on: 24 / December / 2017, 23:45:12 »
Quote from: reyalp on 24 / December / 2017, 16:59:12

Yeah, the fact the spots get sharper with "ND" in makes it pretty clear the aperture is changing.

I think it's safe to conclude the "hidden" ND is actually just a funny way to control the aperture, and these cameras do not actually have a ND filter.

My feeling is we should undefine CAM_HAS_ND_FILTER on these cams, but I'm willing to hear arguments against.

It's hard to compare the spots on the photos because of the different exposures. They look like water spots on the sensor to me (I dropped a camera in a creek once). As I mentioned in this topic, filters change the focal length, so changes in focus with and without a filter doesn't necessarily mean the aperture changed.

Advanced cameras have a lens diaphragm that controls the aperture. Cameras such as the D20 seem to use a plate containing either an ND filter, a fixed hole, or both, that switches in and out.  This is reported by the camera as a change in aperture. The D20 has only 2 possible apertures (at constant zoom). I think it's safe to assume that it doesn't use a lens diaphragm.

So maybe "aperture" is just a funny way to report the exposure change from a hidden ND filter.

In any event, I hope you don't undefine CAM_HAS_ND_FILTER. In my scripts, I have ND filter switch working on the SX260, D20, SX50, and G1X. Without ND filter switching, I would would have to figure out all the aperture equivalents, which would be complicated and camera specific. I see no reason to disable a feature that's working. You don't have to use it, if you can figure out how to do the same thing with aperture changes.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline c_joerg

  • *****
  • 620
Re: Improving CHDK ND filter support
« Reply #42 on: 25 / December / 2017, 02:44:12 »
Quote from: reyalp on 24 / December / 2017, 16:59:12
Yeah, the fact the spots get sharper with "ND" in makes it pretty clear the aperture is changing.
On the cameras with real ND we notice
Quote from: lapser on 16 / September / 2017, 14:06:13
I've noticed a slight magnification change, and slight blurring, in my time lapses before and after an ND filter switch.
So, this should happen on cams with hidden ND’s as well when the have a real ND.

If I do a ‘set_nd_filter(x)’ in CHDKPTP on my S110 this has no effect until I do a half press. Is this the way how the ND changes?
Logged
*

Offline reyalp

  • ******
  • 11592
Re: Improving CHDK ND filter support
« Reply #43 on: 25 / December / 2017, 18:42:05 »
Quote from: lapser on 24 / December / 2017, 23:45:12
As I mentioned in this topic, filters change the focal length, so changes in focus with and without a filter doesn't necessarily mean the aperture changed.
With a real ND filter, the change is very small. Noticeable if you're pixel peeping (as I did here)  but there's no way it can change the DOF like going from F/4 to F/11 does.

There is also no way the effect of an actual ND filter can be ~4 stops when the aperture is open and 1 stop when it's mostly closed. (Of course, you could have multiple ND filters, but there would be no reason to tie this to the aperture)

Quote
So maybe "aperture" is just a funny way to report the exposure change from a hidden ND filter.
No. The cameras that have only an ND are known and understood. The ixus, D20 etc are what we refer to as "ND only" cameras, not "hidden ND". They have an ND, which the canon firmware reports in the aperture propcases, but only has in and out states. What was referred to as a hidden ND was cameras which have an real adjustable aperture, but respond to PutInNdFilter without exposing an ND in the Canon UI. When this was discovered (https://chdk.setepontos.com/index.php?topic=7889.msg95118#msg95118) it was assumed this meant there was actually an ND filter, but IMHO, this has been proven to be a mistake for at least some cameras.

Quote
In any event, I hope you don't undefine CAM_HAS_ND_FILTER. In my scripts, I have ND filter switch working on the SX260, D20, SX50, and G1X.
I am only proposing to undefine it on the cameras which do not physically have an ND filter.  Note there are already many ports which are defined to have aperture only.

For completeness, IIRC a couple of very old A4xx cameras have a swing in aperture which is treated like an ND. I would leave these as ND, since it has only an on/off state and no other aperture control.

Quote
Without ND filter switching, I would would have to figure out all the aperture equivalents, which would be complicated and camera specific. I see no reason to disable a feature that's working.
The current behavior is complicated, camera specific, and only "working" in a very loose sense.

1) One of the problems I identified at the start of this thread is determining the ND value. When the "ND" is actually controlling the aperture, this is not possible, because the "ND" value depends on the aperture you start from.

2) Unlike a real ND, the effect is not necessarily symmetric:  If you are at F/8 and put the "ND" in, you might get ~1 stop, but when you put it out, does it return to F/8, or does to got the max aperture?  It appears to be the latter: c_joerg actually reported this earlier for sx50 and we couldn't explain it at the time.

3) With the current setup, a script cannot reliably control both aperture and ND, because in some some cameras they interact in an unspecified way, but script has no way to distinguish them from cameras that truly have both.

For #3, I suppose we could add a way to identify "cam responds to set_nd_filter by changing the aperture" but this strikes me as a bad way to deal with the fact these cameras were only defined as having an ND due to misunderstanding.
« Last Edit: 25 / December / 2017, 20:54:11 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 11592
Re: Improving CHDK ND filter support
« Reply #44 on: 25 / December / 2017, 19:08:02 »
Quote from: c_joerg on 25 / December / 2017, 02:44:12
On the cameras with real ND we notice
Quote from: lapser on 16 / September / 2017, 14:06:13
I've noticed a slight magnification change, and slight blurring, in my time lapses before and after an ND filter switch.
So, this should happen on cams with hidden ND’s as well when the have a real ND.
As I noted above, this effect is quite small and not the same as a significant aperture change.
Quote
If I do a ‘set_nd_filter(x)’ in CHDKPTP on my S110 this has no effect until I do a half press. Is this the way how the ND changes?
Yes, in general, CHDK script overrides only take effect in the next half press. You can call the underlying camera function directly if you want to put it in with immediate effect, something like
Code: [Select]
on 2> =return call_event_proc('FA.Create')
3:return:0
con 3> =return call_event_proc('InitializeAdjustmentFunction')
4:return:0
con 4> =return call_event_proc('PutInNdFilter')
5:return:0


Edit: for comparison, here's sx710 shots with and without "ND" override. Shot in M, MF, manually adjusted Tv to roughly match exposure.

IMHO, this is clearly aperture change, and is not at all like the small change seen with real ND cams.
« Last Edit: 25 / December / 2017, 19:39:30 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: Improving CHDK ND filter support
« Reply #45 on: 26 / December / 2017, 12:12:12 »
Quote from: reyalp on 25 / December / 2017, 18:42:05

3) With the current setup, a script cannot reliably control both aperture and ND, because in some some cameras they interact in an unspecified way, but script has no way to distinguish them from cameras that truly have both.

For #3, I suppose we could add a way to identify "cam responds to set_nd_filter by changing the aperture" but this strikes me as a bad way to deal with the fact these cameras were only defined as having an ND due to misunderstanding.

What I'm hoping is that for backwards compatibility, you won't disable set_nd_filter() in cameras that may not have an actual ND filter. The function works in my scripts regardless of how it creates the exposure change. It's a very useful function to me.
====
Thanks for posting the comparison photos. They demonstrate clearly that the aperture changed on the sx710.

Another way you can tell that you're not at maximum aperture, with lenses that use a diaphragm to adjust aperture, is that the Sun is star shaped instead of round. The diaphragm doesn't produce a round aperture opening when stopped down. I noticed this effect in my SX50 sunset time lapses with "ND Filter" IN.

But my Canon D20 still gives a round Sun with the ND Filter IN. I think it has a plate with a round hole that flips in front of the lens to change aperture, but it could have an actual ND filter. Can you try your SX710 depth of field test with your D10?
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline reyalp

  • ******
  • 11592
Re: Improving CHDK ND filter support
« Reply #46 on: 26 / December / 2017, 18:07:26 »
Quote from: lapser on 26 / December / 2017, 12:12:12
The function works in my scripts regardless of how it creates the exposure change. It's a very useful function to me.
I understand that, but I'm not sure how to do that while resolving the problems mentioned above and keeping the script interface reasonably comprehensible.

I'm open to suggestions, but I think it should be pretty easy to emulate the current "ND" filter behavior from script. I verified that PutOutNdFilter on these cameras goes to full open, not the previous value, so you just need a set_nd_filter_my() that calls set_nd_filter() on cameras that really have an ND, and goes to full open or full close on cameras without.

It's currently somewhat tricky to get the full open/close values in CHDK, but this will be resolved if the GetUsable*Av functions discussed below are exposed.

Even without those set_av96 clamps to the nearest Canon UI value, so you should be able to just use values beyond the real range. Or use set_av96_direct to get the full hardware limits. In either case, you would have figure out the real available range to compensate for the exposure change, but the same is true for the "ND"

Unlike the current behavior, the above approach would work for all iris-only cameras, instead of the current random subset that incorrectly report having an ND.

If the change is made in 1.5, a compatibility wrapper for 1.4 could potentially implement this for the affected cameras.

Quote
But my Canon D20 still gives a round Sun with the ND Filter IN. I think it has a plate with a round hole that flips in front of the lens to change aperture, but it could have an actual ND filter. Can you try your SX710 depth of field test with your D10?
I verified that elph130 and D10 both have a real ND, DOF does not change significantly.

IMO, almost all the ND-only cameras (ixus/sd/elph, D series, A series without Av mode) have a genuine ND, except for a few of very old ones (notes from srsa_4c suggest A410 through A430, although it's possible others of that era are the same)


Regarding GetUsableMinAv / GetUsableMaxAv

GetUsableMinAv returns the smallest physical aperture (e.g. F/11)
GetUsableMaxAv returns the largest (e.g F/3.2)
The propcase we call PROPCASE_AV_MIN is the minimum av96 value, i.e. the largest physical aperture, equivalent of GetUsableMaxAv >:(
Unlike the propcase, the GetUsable* functions do not require a half press to update.
They call an underlying function which returns both, e.g  GetUsableAvRange(int range[2])
They seem to return the absolute limits, not the Canon UI limits (so sx710 reports Min ~F/10 at full wide and ~F/22 at full zoom) This means that PutInNdFilter on these cameras goes beyond the Canon UI limits, which explains why it appeared to have an effect when Av was maxed out in the UI.
This means the "ND in" value is likely to suffer significantly from diffraction on most cameras. I suspect this explains the loss of sharpness on the near part of my sx710 example.

These eventprocs appear to exist on most if not all cameras with an iris.

They also exist on a few relatively modern ixus/elph cameras: ixus1000, ixus160, ixus200, ixus300, ixus310. A few of these might have a real iris, but I'd be very surprised if a bottom of the line camera like ixus160 did. The functions have real code on these cameras, not just a return 0. (edit: confirmed on elph180, GetUsableMinAv reflects the ND state)

I think it would be good to expose them in script, but two questions are raised
* Naming: Having "min" mean the opposite of the propcase name is sub-optimal. I suggest we expose them as get_min_av96 and get_max_av96, meaning the minimum and maximum av96 value. This matches the propcase and should be relatively unambiguous.
* What to do on cameras that don't have the eventproc
* What to do on cameras that don't have an iris. I don't have any cameras that are ND only and have the eventproc, so I don't know what the underlying behavior is.
* What to do in playback mode. On sx710, they return appear to return wide angle values when the lens is retracted, otherwise the current values. I'd probably make them return nil in Lua.
« Last Edit: 07 / July / 2018, 01:58:53 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 11592
Re: Improving CHDK ND filter support
« Reply #47 on: 19 / February / 2018, 20:19:45 »
I added the min/max aperture functions, trunk r4998.
Quote
* Naming: Having "min" mean the opposite of the propcase name is sub-optimal. I suggest we expose them as get_min_av96 and get_max_av96, meaning the minimum and maximum av96 value. This matches the propcase and should be relatively unambiguous.
Added with these names in Lua. I haven't added them to ubasic yet.
Quote
* What to do on cameras that don't have the eventproc
All cameras with CAM_HAS_IRIS_DIAPHRAGM have the eventprocs detected by the sigfinder. I verified they work from digic 2 (a540) to digic 6 (g7x, sx710)
Quote
* What to do on cameras that don't have an iris. I don't have any cameras that are ND only and have the eventproc, so I don't know what the underlying behavior is.
I made the lua function return nil on cameras without an adjustable aperture. I may change this to return the current actual aperture if it can be done in a reasonable way.
Quote
* What to do in playback mode.
returns nil

With this, the behavior of so-called "hidden" ND cameras could be emulated with something like:
Code: [Select]
local set_nd_filter_orig=set_nd_filter
function set_nd_filter(state)
if get_nd_present() == 0 then
if not get_mode() then
return
end
if state == 1 then
set_av96_direct(get_max_av96())
elseif state == 2 then
set_av96_direct(get_min_av96())
end
else
set_nd_filter_orig(state)
end
end
This could be added to a compatibility wrapper like wrap13.lua for the specific PIDs that had CAM_HAS_ND_FILTER incorrectly defined to preserve 1.4 behavior. I have mixed feelings about this, so input is welcome.

With a relatively easy way to achieve compatible behavior now available, I plan to remove the CAM_HAS_ND_FILTER defines cameras without a real ND in 1.5.
Logged
Don't forget what the H stands for.
*

Offline lapser

  • *****
  • 1093
Re: Improving CHDK ND filter support
« Reply #48 on: 20 / February / 2018, 21:24:44 »
I'm on board with this change now. On the G1X, I should be able to control the aperture AND the ND filter from a script, i.e. for forcing long exposures of waterfalls during the daytime. I'll experiment with aperture control when I get back to scripting. Thanks for figuring this out.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline c_joerg

  • *****
  • 620
Re: Improving CHDK ND filter support
« Reply #49 on: 21 / February / 2018, 01:36:32 »
Quote from: lapser on 20 / February / 2018, 21:24:44
I'm on board with this change now. On the G1X, I should be able to control the aperture AND the ND filter from a script, i.e. for forcing long exposures of waterfalls during the daytime. I'll experiment with aperture control when I get back to scripting. Thanks for figuring this out.

Would be interesting to know in which steps aperture can be changed and how it looks in the video with changing depth of field.
Logged
Pages: 1 2 3 4 [5] 6 7 8 9 10 11   Go Up
« previous next »
 

Related Topics