Improving CHDK ND filter support

reyalp

A fix I added for ixus175_elph180 in r5064 may be relevant to other cameras and the larger ND project.

The ND would go in or out on half press as expected, but would go back to the Canon firmware value for the actual shot. The override is in the usual location, and the other overrides worked normally.

The workaround is to set AV and AV2 propcases as the Canon firmware would when it uses the ND. This both fixes the override, and makes the ND override show as aperture in the exif it would if the Canon firmware activated it.
This is enabled by defining CAM_ND_SET_AV_VALUE ~~to the ND filter value~~ to 1 (edit: the value is now determined from Canon firmware functions). I got the value from GetUsableMaxAv - GetUsableMinAv, but unfortunately these functions aren't available on all ND-only cameras.

IMO, setting the propcase is better behavior even on cameras that don't require it, since it makes the behavior more like the Canon firmware. This only make sense for ND-only cameras, since cameras with both don't account for the ND in the AV value.

On some ND-only cameras (elph130 and elph180 at least), setting the AV propcases in halfpress alone is sufficient to control the ND for the shot. Unlike using PutInNDFilter, this doesn't show up in half press live view (it does show up in the displayed Av). The values require to set the ND in or out don't appear to need to be exact: E.g. if the values the camera would set with and without ND 686 and 328, setting 500 or 700 put the ND in, and 329 or 200 put it out.

reyalp

koshy
So, to sum it up, is it conceivable that IXUS 1000 has neither ND filter nor Iris and all it displays in terms of AV/TV in reality is being done by shutter?

I think this is very unlikely. It seems clear the camera doesn't have a normal ND filter, and does have something else. The first test did seem to show clear exposure differences for Av change.

It's quite possible that CHDK overrides don't work correctly.

Overriding that to "Inf"inity via CHDK doesn't do it. Setting Infinity on the Canon FW doesn't change it either;

According to the source, you must set either MF or AF Lock for CHDK focus override to work.
In chdkptp, you can do this with =set_mf(true) or =set_aflock(true)

The Canon "focus at infinity" setting is just a hint, as you've noticed, the camera still does an AF scan, it just favors far distance.
You should be able to AF lock in the canon firmware by clicking the focus mode button while holding half shoot.

With "ND in" I get a much darker live view upon half press and hold than with "ND out" but the actual photos with all three overrides are identical.

This sounds similar to what I described for the elph180 above, but that workaround doesn't really make sense if there isn't an actual ND filter. You could try overriding both AV and ND at the same time and see if it makes the exposure change reliably
e.g. -nd=in -av=9 and nd=out -av=4

srsa_4c

reyalp
I got the value from GetUsableMaxAv - GetUsableMinAv, but unfortunately these functions aren't available on all ND-only cameras.

The underlying fw function (which delivers both minimum and maximum Av) can be found on a larger set of cameras. Newer DryOS era is the easiest, older models are probably more difficult. Question is, do we want to use the exact offset, or just get away with a sufficiently large value?
And, of course, do you plan to enable this for all ND only cameras?

reyalp

@koshy
Looking at the firmware code a650, sx10 and sx20, I'd be interested to see results for ND on one of these. I've attached a build for sx10 102b with ND filter control enabled. Just taking shots in P mode with ND in and OUT on a scene with some depth should be fine for now.

Also, one thing you could try with ixus1000 is CHDK bracketing in continuous mode.

I'd suggest:
Use a scene where the camera the chooses full wide (e.g. indoor or not direct sun)
Under CHDK enhanced photo -> bracketing in continuous mode
AV Bracketing 2/3 EV
Bracket type -

Set the camera to continuous mode, and shoot 3 or more shots in a burst.

sx10-102b-1.5.0-5069-full-nd-test.zip

837.19KB

reyalp

srsa_4c
The underlying fw function (which delivers both minimum and maximum Av) can be found on a larger set of cameras. Newer DryOS era is the easiest, older models are probably more difficult.

Yeah, I noticed that too, not sure if it's worth finding for ND cameras. It is nice to have identified for analysis. I've been calling it GetUsableAvRange

For ND filter, I think we can get the value directly. I'm still trying to figure out the best way to get it in the sig finder, and what to do with the oddballs

Some notes
All (~~or almost all, still need to check~~ verified all have except the M3 and M10) cameras have ReloadNdFilterAdjustment. The underlying function also appears in the jumptable API.
On cameras without an ND, this function is noop (return, return 0, possibly with some veneers)

On cameras with an ND, it sets a pointer in a struct associated with the ND task, which includes a short with the actual ND value. I verified / found this on d10, elph130, elph180 and g7x. The fact that's its associated with adjustment data suggests it may vary per camera.

There are also other functions that get this value in the ND code. On ND-only cameras, GetUsableAvRange ends up calling one of them. There are also functions that get the current ND value (0 if out, ND value if in), which in turn gives a way to get the current ND state.

With the ND value available directly, there's less need for GetUsableAvRange on ND-only cameras.

Some functions I've identified
get_nd_value: returns the APEX96 value of ND. Firmwares often have two identical copies. This value is always available, even in play mode.
elph130
ff3502dc, ff35031c. value @ *(short *)(0xCF48+0x34)

elph180
ffad8eec, ffad8f2c. value @ *(short *)(0xB5B4+0x34)

d10
Code is a bit different, appears to call a zoom related function, but result doesn't seem to depend on zoom
ffa39d2c, ffa39d94 value @*(short *)(0x9918+0x30)

g7x
fc3cf6e4, fc3cf712. value @*(short *)(0x00026c90+0x34)

get_current_nd_value: returns 0 if out, nd value if in. Firmwares have two or more identical (except for assert line numbers) copies. Calls a function that returns 0/1 for ND state.

elph130
ff35027c, ff3502ac, ff3502ec

elph180
ff35027c, ff3502ac, ff3502ec

d10
ffa39d50, ffa39ce8

g7x
fc3cf6a8, fc3cf6ee,

Underlying function called by ReloadNdFilterAdjustment
elph130: ff434d18

elph180: ffbb55fc

d10: ffab52e0

g7x: fc502c4c (code is somewhat different from the others)

koshy

reyalp
@koshy
Looking at the firmware code a650, sx10 and sx20, I'd be interested to see results for ND on one of these.

OK, I'll try to get that done tomorrow or Tuesday.

reyalp

Here's an updated version of shell script and spreadsheet from https://chdk.setepontos.com/d/13228/51

The OS and PID columns allow sorting in roughly chronological order (but PIDs are not exactly in sequence with release date).

IrisActuator.c and NdActuator.c seem to be the most reliable indicators. The tasks are similarly reliable except on very early cams. ReloadNdFilterAdjustment not being noop may also indicate real ND, but I haven't checked all. ReloadIrisAdjustment appears to have some code even on ND only cams.

The EOSM cams have neither Iris not ND tasks / .c files, which makes sense.

Starting around ixus160 (DryOS 55p6, 2014), Canon exposed more AV related eventprocs on ND only cams, including GetUsableMinAv and GetCurrentIrisPosition.

Cameras with open questions are:

* a650, sx1, sx10, sx20. All have what looks like ND code, but aren't defined as ND. ReloadNdFilterAdjustment does something on these cams. Manuals and online specs don't appear to mention ND.

ixus1000_sd4500 - unclear, code looks like it should be Av only, port has problems

sx400 - looks like it should be Av only, like sx410.

As of trunk 5069, I removed the ND define from tx1, ixus200 (based on koshy testing and firmware code) and sx260 (which I missed in the earlier cleanup)

avnd.sh

2.85KB

avnd-5069.csv

7.09KB

koshy

reyalp
I've attached a build for sx10 102b with ND filter control enabled. Just taking shots in P mode with ND in and OUT on a scene with some depth should be fine for now.

The override did not have any effect. In and Out are the same. http://www.filedropper.com/sx10nd

srsa_4c

reyalp
get_nd_value: returns the APEX96 value of ND.

Index: tools/finsig_dryos.c
===================================================================
--- tools/finsig_dryos.c	(revision 5071)
+++ tools/finsig_dryos.c	(working copy)
@@ -335,6 +335,7 @@
     { "exmem_alloc" },
     { "exmem_free", OPTIONAL|LIST_ALWAYS },
     { "free" },
+    { "get_nd_value", OPTIONAL },
 
     { "kbd_p1_f" },
     { "kbd_p1_f_cont" },
@@ -2092,6 +2093,7 @@
     { 23, "get_string_by_id", "NoError", 16,                                    99,     99,     99,     99,     99,     99,     99,     99,     99,     99,     99,     99,     99,     99,     99,     -2 },
     { 23, "EnableHDMIPower", "HDMIConnectCnt", 9,                               99,     99,      1,      1,      1,      1,      1,      1,      1,      1,      1,      1,      1,      1,      1,      1,},
     { 23, "DisableHDMIPower", "HDMIConnectCnt", 9,                              99,     99,      3,      3,      3,      3,      3,      3,      3,      3,      3,      3,      3,      3,      3,      3,},
+    { 23, "get_nd_value", "IrisSpecification.c", 25,                            -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,     -1,},
 
     //                                                                           R20     R23     R31     R39     R43     R45     R47     R49     R50     R51     R52     R54     R55     R57     R58     R59
     { 24, "get_string_by_id", "StringID[%d] is not installed!!\n", 64,           0xf000, 0xf000, 0xf000, 0xf000, 0xf000, 0xf000, 0xf000, 0xf000, 0xf000, 0xf000, 0xf000, 0xf000, 0x0000, 0x0000, 0x0000, 0xf000 },
Index: tools/finsig_vxworks.c
===================================================================
--- tools/finsig_vxworks.c	(revision 5071)
+++ tools/finsig_vxworks.c	(working copy)
@@ -338,6 +338,7 @@
     { "exmem_alloc" },
     { "exmem_free", OPTIONAL },
     { "free" },
+    { "get_nd_value", OPTIONAL },
 
     { "kbd_p1_f" },
     { "kbd_p1_f_cont" },
@@ -1312,6 +1313,7 @@
     { 15, "wrapped_malloc", "\n malloc error \n", 0x01000001,                    0x0010 },
     { 15, "IsStrobeChargeCompleted", "\r\nCaptSeq::ChargeNotCompleted!!", 0x01000001 }, // ixus30, 40
     { 15, "get_resource_pointer", "Not found icon resource.\r\n", 0x01000001,    0x0008 },
+    { 15, "get_nd_value", "IrisSpecification.c", 0x01000001 },
 
     { 16, "DeleteDirectory_Fut", (char*)DeleteDirectory_Fut_test, 0x01000001 },
     { 16, "MakeDirectory_Fut", (char*)MakeDirectory_Fut_test, 0x01000001 },

This appears to find get_nd_value on almost all ND-only models - exceptions are the ixus 30 and 40. Did not verify the results yet.
The presence of "IrisSpecification.c" seems like a good indicator for an ND-only camera.

reyalp

srsa_4c
This appears to find get_nd_value on almost all ND-only models - exceptions are the ixus 30 and 40. Did not verify the results yet.

Nice. I haven't had time to check whether it's correct, but the code found for earlier cams like ixus700_sd500 seems quite different.

ixus700_sd500 also has eventprocs like "NdActuator.IsNdFilterActive" "NdActuator.GetNdFilterDeltaEv", "NdActuator.GetNdFilterDeltaEvAdjustValue"

The presence of "IrisSpecification.c" seems like a good indicator for an ND-only camera.

Agreed. Comparing with my spreadsheet, only ixus 30 and 40 don't seem to match. I noticed that string before, but assumed it must be present on iris cams too 😳

reyalp

koshy
The override did not have any effect. In and Out are the same.

Thanks. Maybe it's just leftover code on those cams.

I noticed that sx10 has two sets of ND functions in the canon firmware. CHDK uses TurnOnNdFilter / TurnOffNdFilter which call into NdActuator.c functions

PutInNdFilter / PutOutNdFilter also exist, but call IrisController.c functions.

srsa_4c

reyalp
the code found for earlier cams like ixus700_sd500 seems quite different.

Indeed. The oldest cam I looked at was the a410, looks like older ones have a version of that IrisSpecification.c routine that does not call get_nd_value - those hits are incorrect.

reyalp

ixus40_sd300, ixus50_sd400, ixus700_sd500 and s2is have the NdActuator.* eventprocs

I think GetNdFilterDeltaEvAdjustValue is the ND value and GetNdFilterDeltaEv is the current value.

srsa_4c

reyalpI think GetNdFilterDeltaEvAdjustValue is the ND value and GetNdFilterDeltaEv is the current value.

Confirmed on Ixus40 (GetNdFilterDeltaEvAdjustValue is constant 189, GetNdFilterDeltaEv is 0 when ND out, 189 when in).

edit:
I'll continue working on the rest of the stuff mentioned here, soon.

reyalp

srsa_4c
I'll continue working on the rest of the stuff mentioned here, soon.

Thanks. I'm happy to have your help with this, but if you'd rather work on other stuff, I can probably take it from here.

My goal is to end up with script functions
1) get_nd_value - same as the function we've been discussing. The main thing left is finding a suitable match for cameras with both iris and ND. Adding sigfinder detection of what a camera has may be useful to decide which to use, as well as flagging possible errors in ports. I started this in finsig_thumb2, but all the d6 cameras are iris only or both so it doesn't cover the ND only case.

2) determine whether ND is currently in or out. I'm not sure if this is better as a boolean, or something like GetNdFilterDeltaEv, or both. With get_nd_value it's pretty trivial to go from one to the other, so in terms of finding firmware functions, whichever is easiest is fine.

reyalp

reyalp
The main thing left is finding a suitable match for cameras with both iris and ND.

On g7x, g16, g12 and g9,
PutInNdFilter -> first sub called after ClearEventFlag -> first call is get_nd_value
This looks like it should cover most "both" cameras. g7 (the old vxworks one, not g7x) looks a bit different.

On cameras with an iris where ND functions control the iris, the call where get_nd_value would be is GetUsableAvRange. Many ND-only cameras (elph180 and d10 at least) also call GetUsableAvRange in this position.

edit:
In trunk 5077, I added a match based on PutInNdFilter for digic 6 iris + ND cams. I also added GetUsableAvRange to the CSVs, because it's useful to see in disassembly.

waterwingz

reyalp
On g7x, g16, g12 and g9, PutInNdFilter -> first sub called after ClearEventFlag -> first call is get_nd_value

I've only been half way paying attention to this (sorry) but I can of course make the G16 changes and test. Just need to figure out what you've done.

What about the G10?

Or the S90-S110 series cams that have iris and ND filter?

reyalp

waterwingz
I've only been half way paying attention to this (sorry) but I can of course make the G16 changes and test. Just need to figure out what you've done.

At the moment, I'm trying to find code paths that are relatively easy to add to the sig finder. I figure if g9 and g7x and a few cameras released in between obviously the same code, others in the same time span probably do as well.

You could check that the get_nd_value added in 5077 for g16 returns something that looks like an ND value (using call_func_ptr with the address from stubs_entry), but I'm pretty confident the match I added is right.

reyalp

In trunk 5079, I added a finsig_thumb2 match for get_current_nd_value (aka GetNdFilterDeltaEv). This seemed easier to match than the one that just returns the in/out state.

This again is only valid iris + ND cams, but the logic should be valid for pre-digic 6.

Addresses below are from g7x 100d

0xfc4f029b ShowCurrentExp_FW -> fc4f028c -> fc4f025c
fc4f025c calls fc321abe, which fills an array of shorts with exposure values, and then prints them with a string like "Exp Av %d, Tv %d, Gain %d\n"

The function fc321abe that fills the array calls a veneer of the function that gets the current ND value and stores the result in offset 8. On no-ND and ND-only cameras, there is a function that returns 0 instead of the veneer.

reyalp

Here's a slight update to srsa_4c's patch posted earlier. It just uses the eventprocs to find get_nd_value and get_nd_current_value on the old vxworks cams

It looks like GetCurrentAvValue should be usable to find get_nd_current_value on later ND-only cams, but there needs to be a way to avoid bogus results on cameras that have an iris.

nd-filter-pre-d6.patch

2.98KB

« Previous Page Next Page »