Working on the ND stuff and trying to figure out which cameras have a real aperture lead me down some other rabbit holes
Some general observations:
Modern cameras (starting around G12, maybe) need CAM_AV_OVERRIDE_IRIS_FIX to control the aperture in continuous shooting. This calls MoveIrisWithAv to set the aperture rather than just setting propcases. However, the define is currently only set up to work in bracketing, so scripted aperture changes in continuous mode (ala rawopint etc) doesn't work.
This should probably be changed to apply to any set call while in shooting, but the set_now/set_later logic makes it somewhat complicated. Also, it doesn't appear to be required "quick" mode, but if we just check get_shooting it would still be applied there. This would probably be harmless.
It's likely that some cameras which need this define don't have it set, or vice versa.
Some current CHDK functions use GetCurrentAvValue. This function (also discussed in
https://chdk.setepontos.com/index.php?topic=13508.0) returns the current value (not a half press value or next shot setting) so mixing it with propcase values that only update on half press seems suspect. The history of this usage is unclear to me, but it seems to have been around for a long time. It's used in
* shooting_get_real_aperture - used only for misc display and _min_real below
* shooting_get_min_real_aperture - used in shooting_get_subject_distance_
* shooting_update_dof_values
Attached avtest.lua script is similar to ndtest and isoinc for aperture.
By default, the script will step through aperture values from min to max in 1/3 stops, compensating with shutter to attempt to the keep the exposure constant. It has the usual single/quick/cont modes. If it prints "no warnings" aperture control probably works with the selected settings, otherwise there are possibly problems with the scene or bugs in the port.
You can also use it to run through the available range in 1 APEX*96 steps to measure the precision of aperture control.
Testing on g7x, control is quite good (see attached chart, "m96_err" is the difference between predicted meter and actual in APEX96. I suspect the biggest outliers are ambient light changes), so smoothly ramping through the AV range for DOF effects in timelapse should be totally viable with modest software de-flicker.
Test video
edit:
Youtube compression makes it harder to see what's happening, link to original file
https://app.box.com/s/r1eg4is9dqrp3kkpp0r3x458wqrlnxixedit 2018 09 11:
Updated script to handle ISO better
edit 2018 09 13:
Fix formatting of aperture values in log
edit 2018 10 06:
* Error now calculated from baseline shots at the starting aperture
* Log av96_err (Av compared to get_current_av96) and m96_err_cur (meter 96 error assuming get_current_av96 is correct)
