Situations where clouds keep pushing in front of the sun are extremely difficult.
Agreed. Reflection of that on water too. But I think there is room for improvement. I have a few other changes I should finish now that ND control is in CHDK stable, so maybe I'll play with it a bit. I think slowing down the change if a lot of pixels are near the over-exposure threshold could work quite well. Right now (at least if I'm interpreting my old code correctly
) it doesn't distinguish if the "overexposed" is just over the threshold or totally saturated. If it did, it could be less aggressive in the first case.
I had already considered another option: to deactivate the exposure control for a certain time using an external USB switch or to only allow a control for overexposure.
Yes, my thought of interactive control was more for development/testing than for actual shoots.
edit:
I think I may have come up with an approach to deal with the overexposure problem properly.
One of the difficulties with overexposure is you can't predict how much a given exposure change will affect it: That is, if you have saturated pixels, you can't predict what exposure change is needed to bring them below saturation. The Sun may barely change with 5 stops, where a cloud might be completely unsaturated with a quarter stop.
However, this isn't true in the other direction: For a given positive exposure change N, all pixels with values above (overexposure threshold - N) will pass the threshold, and this number can be easily obtained from the histogram. So the exposure algorithm can take the exposure change calculated from other inputs, calculate how many additional pixels would be pushed into over-exposure, and adjust accordingly to keep it below the limit.
In practice, some knowledge in the other direction should be possible too: The script uses a range (default 1/4 stop below white level) for overexposure, so (+/- uncertainty how the sensor behaves very near saturation) it can estimate a minimum number of pixels that would be brought below the threshold, or even calculate it exactly if the exposure change significantly smaller than the range.
This won't be trivial to integrate into the existing algorithm, but I think it's the right approach, and may allow eliminating some of the other hacks I introduced trying to stop it from bouncing around the limits.
