exposure compensation in XMP (deflick.mo)

Started by Erik Krause, November 10, 2015, 11:07:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Erik Krause

Hello,

I tried aettr with deflicker module for exposure normalization. aettr works a treat! But if I use the XMP with Adobe Camera Raw the exposure correction value has the wrong sign. If I understood correctly the XMP data should cause all images shot with the same ettr settings to be of visually equal brightness. However, they came out very different. But if I change the sign of the correction, they look the same.

F.e. for one image ACR showed +0.04 EV and +1.31 EV for the other. The second image was much brighter than the first. When I change the values to -0.04 and -1.31 both images appear to have the same brightness.

Do I use the XMP files the wrong way (loading the corresponding CR2 files into ACR loads the XMP files automatically) or is this a bug?

magiclantern-Nightly.2015Nov07.5D2212, photoshop CS6 with ACR 9.1

best regards
Erik

Erik Krause

I created issue #2402 on bitbucket. I'd like to know whether this can be confirmed or refuted by anyone. It seems unlikely that I'm the first to discover it since I originally found it with a nightly from May 2015.

Audionut

Looks to be working fine here, although maybe a little counter-intuitive.

The default settings has Deflicker percentile @ 50% and Deflicker target level @ -4 EV.  This says, find the 50% brightness point of the image and place it at -4 EV.

So imagine you shoot a clear sky with ETTR, the deflickered image would have a brightness level around the midtones.  Because a clear sky has little dynamic range, 50% brightness represents almost the entire image, and so deflicker would place this image @ -4 EV.  In other words, the deflickered image would look dull because it is being rendered as a midtone instead of a highlight.

Now imagine that you do not change exposure settings, but pan the camera so that it includes the sky, but some darker content also.  Here, the 50% brightness point is probably somewhere between the sky and the dark areas, so the deflickered image probably won't change much, because the 50% brightness point of the image is already around -4 EV.

Now imagine that you do not change exposure settings, but pan the camera so that it only includes very deep shadows.  Here, the dynamic range is also probably small, but the image has been shot as a shadow.  So the 50% brightness point is somewhere in the shadows, and hence, the deflickered image will be brighter since deflicker will push this 50% brightness point to -4 EV.

My current panorama method of choice when shooting a large dynamic range scene is using dual ISO.  Since you can shoot around 12 EV of useful dynamic range with dual ISO.  So I will generally frame the brightest portion of the image first, ETTR this @ ISO 100 with dual ISO enabled and then dual ISO will take care of the darker areas of the panorama.  Since exposure settings don't change, it's very easy to exposure match the images.  Just enable the --same-levels option when processing the dual ISO images, and ensure the same WB.

Erik Krause

Could well be it works as intended and I have wrong expectations. My thought was that aettr shoots such, that little highlights are clipped and SNR is high. This works very well. My hope was, deflicker.mo writes XMP files, that adjust images in ACR such, that the brightness of same details matches. For a timelaps that would mean that bright lights that show for a short time don't cause the respective image to have different over-all brightness. Same if I f.e. change zoom or move the frame just a bit. I know very well that I simply can shoot with a fixed exposure, but this way I might clip the highlights.

After first tests I was disappointed that images shot as described above show very different over-all brightness, even further apart than without XMP exposure compensation. I tried to compensate the exposure manually and landed at (roughly) the inverse values. In fact the exposure was perfectly normalized when I simply changed the sign. Hopefully I find some time tomorrow to do some further tests, especially in comparison to UFRaw...

mothaibaphoto

@Erik Krause
It's always better not to spend camera battery by work which can be done (and even much better) in post. All you need from camera for timelapse- is a sequence of correctly exposed images. Then, this script works just fine.

Erik Krause

Further tests show that apparently my understanding was wrong. Sorry for the hassle.

This leads to a question: Is there a way to use AETTR and record the deviation of a preset exposure in XMP? If I f.e. Set exposure to f/8, 1/100, 100ISO and AETTR changes exposure to f/8, 1/200, 100ISO could ML then write a XMP that causes the images to look equally exposed in ACR / Lightroom?