Exposure override issues on DIGIC 6 cameras

Can somebody with this camera check whether CHDK exposure overrides remain effective after the shutter is held halfway down for a few seconds? On the M10, they are getting overridden by the Canon firmware in all shooting modes except M. That means, when CHDK overrides are set, they are reflected on the Canon overlay for a few moments after a half press, then the exposure parameters return to Canon calculated values.

(bump)
I'm seeing the same thing on my G16 port. Except the CHDK overrides work in AUTO or M modes.  In P, Tv, Av, or Scene modes,  the CHDK override values are overwritten in about one second.   If I put the camera into Canon MF mode, the CHDK overrides then work properly.   

I'm currently thinking this is a function of where the
BL shooting_expo_param_override is inserted into capt_seq.c

Quote from: srsa_4c on 14 / April / 2017, 07:18:49

Can somebody with this camera check whether CHDK exposure overrides remain effective after the shutter is held halfway down for a few seconds? On the M10, they are getting overridden by the Canon firmware in all shooting modes except M. That means, when CHDK overrides are set, they are reflected on the Canon overlay for a few moments after a half press, then the exposure parameters return to Canon calculated values.

(bump)
I'm seeing the same thing on my G16 port. Except the CHDK overrides work in AUTO or M modes.  In P, Tv, Av, or Scene modes,  the CHDK override values are overwritten in about one second.   If I put the camera into Canon MF mode, the CHDK overrides then work properly.

Okay, that's at least 3 ports affected by a similar anomaly, time to split this into a separate thread.

I'm currently thinking this is a function of where the

Code: [Select]

BL shooting_expo_param_override is inserted into capt_seq.c

I don't think so (at least not in my case). When this is happening on the M10, capt_seq_task isn't getting any messages - the exposure recalculation is done in a different task. It surely affects the propcases we're using (as the CHDK override display also reflects the recalculated values, in addition to the Canon overlay). That's what I'm trying to track down (finding out which task sets "our" propcases back), with no luck so far. Worth to note that there are multiple versions of SetPropertyCase, out of which we only use one.

@reyalp
Can you split posts starting here to a new thread titled something like "Exposure override issues on DIGIC 6 cameras"?

@WW
Do you see camera log entries like the following when the exposure parameters change back to Canon (re-)calculated values?
00016350: UI:ShootSeqToUI:0x00003157:adr:0xfc2a50cb,Para:-64335669
00016360: UI:DSIC:e3,0
00016360: UI:VTMLock
00016390: UI:VTMUnLock
00016750: UI:ShootSeqToUI:0x00003157:adr:0xfc2a50cb,Para:-64335669
00016750: UI:DSIC:e3,0
00016750: UI:VTMLock
00016790: UI:VTMUnLockThese (ShootSeqToUI, DSIC) are the results of a callback routine that notifies the Canon UI to update the exposure parameters on the screen. I managed to re-set the callback to a nullsub, but that only affected the Canon UI (the values still got recalculated).
I also know that, at least PROPCASE_TV, is not set via the SetPropertyCase routine. From another log, I see heavy activity in BrtMsrTask when the exposure is recalculated during half press. I can't yet prove that that task is to blame though.
If I lock AE (using the Canon controls), exposure is no longer recalculated during half press and our overrides succeed.

@reyalp
Can you split posts starting here to a new thread titled something like "Exposure override issues on DIGIC 6 cameras"?

Done. If there are more posts I should move over to this thread, let me know.

Have you tried logging the propcase values from the remote hook? That could tell you whether the propcases are being changed or bypassed.

@WW Do you see camera log entries like the following when the exposure parameters change back to Canon (re-)calculated values?

Sorry - kind of offline for a few days.  Will check this weekend hopefully.

Done. If there are more posts I should move over to this thread, let me know.

Thanks. The rest of posts that mention this can stay where they are - the problem is hopefully described well enough here.

Have you tried logging the propcase values from the remote hook?

Not yet. One of the propcases involved (PROPCASE_TV) is special, because it is queried directly by the CHDK OSD. It does show the recalculated value as soon as the Canon overlay does - that means this propcase is affected directly. Unfortunately, I have not been able to find the Canon task that sets it back (not all propcase setter functions can be tapped). I'll try the other involved propcases next.

@WW
OK.

I'd forgotten about this thread until reyalp pointed it out today on IRC. I've been working with his help trying to discover why G16 exposure overrides are not working correctly. 

The current G16 code will shoot using the shutter button with CHDK menu based overrides enabled and the resulting exposure is as expected based on the values set in the overrides.

However, when shooting via a script with either shoot(),  press & release keys, or levent PressSwTwo & PressSwOne,  the override values set by  set_tv96_direct( ), set_av96( ), set_sv96( ) are ignored.

Looking at the camera logs,  when shooting via script (in <ALT> mode) the overrides get reset in case 1 of the capt_seq.c big switch statement - the part that handles the actual full press shot.  It enters the case with the exposure props set to the override values but by the time it reaches the USB remote hook, those values have been reset to the "normal" shooting exposure values.

I can see some of the log entries srsa_4c mentions in his previous post in logs where the overrides get "cleared" and not used (while transitioning through case 1). I'll do some more tests to see if those are always missing when the overrides actually gets used (in normal shooting mode).

Update : my problem turns out to be somewhat unrelated - my key_mask values were invoking the "hotshoe disables overrides" problem when doing any kind of scripted shooting.  Which suggests that the "hotshoe disables overrides" problem it related to some task interfering in the capt_seq.c shooting process.