raspicam --ev -10..10 is not EV about userland

[JamesH65]

I don't believe EV has to be measured in particular increments. We simply specify it from -10 to +10, giving a finer grained measure than, for example, 3rds, or halves. You can assume (I think) that -10 would be, for example, max -ve on a actual camera (independent on whether the camera is set up for EV increments in 1/3rds or 1/2's), and +10 will be the max positive EV.

[towolf]

The definition of Ev is that an increment of 1 corresponds to 1 stop.

For example, if you want to lower ISO from 400 to 100 (-2 stops) and have a correct exposure you would have to compensate with Ev +2, which ought to increase exposure time by 2 stops since aperture is fixed.

So the question is, does the camera use a conventional exposure calculation internally, and there is some evidence that it does.

[JamesH65]

The camera code need to be suitable for multiple customer, who often require different EV increments. My DSLR allows you to specify the increment. This means that the range needs to be fine grained enough to cope with that. So our -10 to +10 corresponds, I think, to to -3 to +3 stops. I'll need to double check the code.

[6by9]

The command-line/MMAL value for EV is counting in 1/6ths of a stop. Therefore ev=6 would be +1 stop. The range is up to +/- 24, or +/- 4 stops.

I would update the API, that would break any app that is expecting the current behaviour.
(I can switch MMAL to take either an int32 or a MMAL_RATIONAL_T, as the difference can be deduced by the different size of the parameter structure - I'll add it to the to-do list, but it won't change raspistill).

[waveform80]

Ah, sounds like this might be related to an issue I've run across in picamera before: waveform80/picamera#71 - when setting certain +ve EV values, if you subsequently query the EV value it comes back as the value specified minus one.

However, an eagle eyed user noticed (in the linked issue) that values where %3==0, always come back correct. Sounds like there's some sort of floor rounding going on (which would explain why the -ve values always work).

[6by9]

Groan. That rounding bug was fixed on our main dev branch a year ago, but never got pulled to the Pi tree. Time for another cherry-pick.

[towolf]

Thanks for the info.

If you don’t want to change the range mapping, please at least document the step size of 1/6 EV in the help and the usage string of raspi{vid,still}.

[6by9]

Firmware change for fixing the EV rounding has been pushed internally. It will be released when Dom does his next release cycle.
I'll leave the help text update to JamesH.

[6by9]

Firmware change for fixing the EV rounding has been released with commit raspberrypi/firmware@9c7c2cd
MMAL_PARAMETER_EXPOSURE_COMP will now take either a MMAL_PARAMETER_INT32_T or MMAL_PARAMETER_RATIONAL_T, and do the appropriate thing based on the size of the parameter.

I'll leave the help text update to JamesH.

[Ruffio]

@towolf is this still an issue?

[6by9]

PR #279 now merged which adds help text stating that EV is in steps of 1/6 stop.
Please close unless you think there is something further to do.

[Ruffio]

@towolf is this still an issue? It looks like it has been solved.

[towolf]

No