A650, Allbest 100d - Shutter Override and Bracketing

[Sess]

I've noticed a problem when using shutter speed override and bracketing at the same time. If you override the shutter speed to something way faster than the camera would normally do, such as 1/64000, and also enable bracketing at say 1 ev, the first shot will be 1/64000 like you expect. However, subsequent frames will have the shutter speed bracketing from the camera's default highest speed, which is 1/2000.

So while you were expecting shots with shutter speeds like this:

1/64000
1/32000
1/16000
1/8000
1/4000

You will instead get shutter speeds like this:

1/64000
1/2000
1/1000
1/500
1/250

Does anyone know of a solution to this problem? I'm using Allbest build for A650IS 100d-51. I'm not sure where I got it because whenever I look for the Allbest builds for my camera I only ever find 100d-50.

[fe50]

-> CHDK Autobuild server with the latest versions: http://mighty-hoernsche.de/

[Sess]

I finally got around to testing this with the latest release (a650-100d-0.9.7-725-full).

I did two tests and each had two sections. The first section was using bracketing without overriding the shutter speed, and the second used bracketing and shutter override.

For the first test I set the aperture to 8, the shutter speed to 1/2000 (the camera's normal max), bracketing to 1 EV, and set the camera for 4 shots. The expected, actual, and JPG EXIF shutter speeds are all identical. Here are the results:

Frame #	1	2	3	4
Shutter Speed	1/2000	1/1000	1/500	1/250

Next I left everything else the same and set the shutter override to 1/50000. This time, the expected, actual, and exif speeds did not match. I determined the actual speeds by comparing the images to the previous set. With bracketing at 1 EV, it was easy to see which images were at the same shutter speed.

Frame #	1	2	3	4
Expected Speed	1/50000	1/25000	1/12500	1/6000
Actual Speed	1/50000	1/1000	1/500	1/250
JPG EXIF Speed	1/2000	1/1000	1/500	1/250

I started to suspect that while the shutter override controlled the speed of the very first frame, for the speed of subsequent frames, the CHDK bracketing program didn't look at the override speed and instead looked at whatever speed the camera was set to by its own, non CHDK controls (as in the speed it would do without the shutter override). To test this, I did another series starting at a much lower shutter speed. First are the results without using shutter override. Again, the expected, actual, and exif speeds were the same.

Frame #	1	2	3	4
Shutter Speed	1/200	1/100	1/50	1/25

Next I again left everything else the same, including the cameras own shutter speed set to 1/200. I then enabled shutter override and set it to 1/50000.

Frame #	1	2	3	4
Expected Speed	1/50000	1/25000	1/12500	1/6000
Actual Speed	1/50000	1/100	1/50	1/25
JPG EXIF Speed	1/2000	1/100	1/50	1/25

This data appears to confirm my suspicions. For this last test, the first frame used the shutter override speed like it was supposed to, but when bracketing took over for the next three frames, it didn't look at the override speed, it instead looked at the camera's own shutter speed, which was still set to 1/200. In seeing that, it assumed the first frame must have been at that speed, so the next three were at 1/100, 1/50, and 1/25.

Also, the JPG EXIF data continues to be wrong whenever an override is set outside the cameras normal boundaries. While the actual speed of the first frame was 1/50000, the camera refused to write anything higher than 1/2000. This same problem occurs with exposures longer the camera's maximum of 15 seconds. If I override it to 65 seconds, the exif data will still say 15. However, whatever causes the exif data to be wrong seems to be different from the bracketing problem. If they both looked at the same thing, I imagine the actual speeds of this last round would have been 1/50000, 1/1000, 1/500, 1/250 instead of 1/50000, 1/100, 1/50, 1/25.

[fudgey]

See EXIF Canon MakerNotes section for the overrided values in the JPEG... (and remember that even those don't mean that the camera was really capable of that setting, just that it really tried).

[Sess]

See EXIF Canon MakerNotes section for the overrided values in the JPEG... (and remember that even those don't mean that the camera was really capable of that setting, just that it really tried).

Ah, I see. That's great. I can use the ExifTool GUI to edit the data to match the actual shutter speeds. And yes, I realize that the Maker info is simply what the camera attempted to do, but I know the limitations for my camera, for instance at f 8.0, it can do 1/64000. So as long as I'm within the camera's boundaries, I will assume the Maker data is more or less accurate.

Anyway, the EXIF data is really only a minor concern. The main issue is the bracketing problem. I just performed another test and found out something interesting. Before I was trying to start at a speed that was beyond the camera's default range (such as 1/50000) and bracket from there. But I just did a test where I started at 1/2000 (the camera's default fastest speed) and had it bracket towards faster speeds at 1 EV. Doing it this way, I did not have to use the shutter speed override. And so the first frame was 1/2000, bracketing saw that, and made the next shot 1/4000, 1/8000, and so on. The actual speeds of these frames were all correct (except the EXIF data of course).

So while it is a problem that bracketing only looks at the camera's normal (non-override) shutter speed for its starting point, bracketing has no problem going outside of the camera's normal boundaries. You just have to have a starting point that is within those boundaries. So if you want to bracket at really high speeds, your first shot must be at 1/2000 (or slower) and increase in speed from there. And if you want to bracket at really slow speeds, your first shot must be at 15s (or faster) and slow down from there. This is certainly a solution, but it can make it more difficult to set up your bracketing shots in some cases. I still think it would be best if CHDK bracketing checked to see if the shutter speed is being overwritten, and if it is, use that as the starting point instead.

[fudgey]

Confirmed on a570 trunk727 and agreed that it shouldn't work like that. Moreover, I believe it affects ISO and Av bracketing too but for those I'm not very interested as I find those two useless. I don't have the guts to try out subject distance override + bracketing...

Added a ticket: http://chdk.kernreaktor.org/mantis/view.php?id=249

[Sess]

Oh hey, nice work. My complaining might actually lead to results!

Anyway, I agree that this problem likely exists for all forms of bracketing, but I don't use the others at all either. Though, I can imagine uses for subject distance bracketing (that's focus bracketing, right?). If you're doing macro work with the aperture wide open, it could be interesting to bracket the focus a bit. Then later you can choose which one looks the best.

As for aperture bracketing, the last time I tried that (long time ago) it didn't seem to work right. Neither did aperture override. I think the lens' focus and aperture are linked such that if the aperture changes, the focal point changes as well. So if you focus on an object and then bracket the aperture, the focus will be wrong on all but the first shot. However I could be completely wrong about this. I only tried it once, got poor results, decided it was useless anyway (and so didn't try it again), and sort of came up with my own theory as to why the results were poor, without ever actually testing my reasoning (again, because who cares about aperture bracketing).

[reachfish]

Thanks for you!

[fudgey]

For the hasty, I cooked up a patch to fix Tv bracketing during shutter speed override. http://chdk.kernreaktor.org/mantis/view.php?id=249.

I think it's probably not worth looking at ISO and Av overrides for the same bug, because there's very little reason to try having both override and bracketing for those two enabled simultaneously since the manual controls in these cameras can go pretty close to the physical maximum values for both ISO and Av.

Tv is way different in this regard, since it's Ev range is huge compared to Av and ISO (we're working with somewhere around 5 or 6 Ev for aperture and ISO compared to 23 Ev for Tv, now extended even further in experimental builds indefinitely towards ultra long exposures for a few select vxworks cameras!)

[Sess]

Any progress on this bug fix making it to a real release?

[Sess]

Or any chance of getting the version of the DISKBOOT.BIN file with this patch already applied? I don't know how to compile this myself...

[fudgey]

Thanks for the reminder Sess! Patch applied to trunk 759. It only fixes Tv bracketing during Tv override. Updated builds will be available when the autobuild does its magic.

http://tools.assembla.com/chdk/changeset/759