exposure correction value in XMP has wrong sign

Issue #2402 invalid
Erik Krause created an issue


when using deflick.mo with aettr for exposure normalization the generated XMP files seem to have an exposure compensation value with wrong sign in adobe camera raw.

If I load CR2 files (with corresponding XMPs) shot with the same aettr settings into ACR their apparent brightness is very different. If I invert the sign of the exposure compensation value, they look equally bright.

Comments (20)

  1. Alex

    That's interesting. How did others use this feature so far?!

    As I don't have ACR, I'll wait for others to confirm the issue.

  2. Erik Krause reporter

    I was surprised myself, since when I found it first it was with May 2015 nightly. I then updated to most recent nightly and found the behavior unchanged. Unlikely that I'm the first one...

  3. Erik Krause reporter

    Yes, I saw, but it started 2013. Only the last posts are from 2015 and the behavior might have changed meanwhile. And f.e. http://www.magiclantern.fm/forum/index.php?topic=5705.msg149816#msg149816 might point in the same direction. However, they discuss timelaps most of the time, where the frame content changes only in terms of brightness. I want to try it for panorama shooting, where the goal is to have equally bright frames with different content. May be I misunderstood the functionality. I used live view and the Press SET method to get the ettr right (if that plays a role). I'll do more tests next weekend...

  4. Alex

    Do you mind testing older builds as well?

    For panoramas, you may get better results in M mode, with same exposure settings on all frames (maybe with dual ISO enabled, and some tonemapping in post).

  5. Audionut

    Inverting the sign equally for each image does not change their relative brightness. They are still 1.27EV apart.

    edit: Have I mentioned I suck at maths.

  6. Erik Krause reporter

    @ a1ex: I can test older builds as well. How far should I go back? The ML 2013 Version on my other CF-Card doesn't have deflicker yet. Thanks for the panorama hint. I'm shooting panoramas in M mode since 16 years and wanted to try something new. @ Audionut: They are still 1.27 EV apart, but now the brighter image is the darker one and vice versa. :-)

  7. Alex

    Another question:

    If you increase the exposure compensation value in the XMP (crs:Exposure2012), does the image get brighter or darker in ACR?

  8. Erik Krause reporter

    I did a quick test with ML 2013Jun29.5D2212 and indeed it seems to work the other way round. I did the following: Since there is no ettr module I used P mode and intervalometer. I pointed the camera below my computer monitor on the desktop, which is relatively dark for the first shot and directly to the monitor for the second. Exposure for the first was 2.5s f/4, the second 1/13s f/4 (both ISO 100). Loading both images in ACR shows an exposure compensation of -1.96 for the first and +1.15 for the second. The surroundings of the monitor have relatively equal brightness with these settings. If I set exposure to 0.0 the first one is much brighter than the second one.

    Then I did exactly the same with ML 2015Nov07.5D2212. Exposure for the first image is 2.5s f/4, the second 1/40s f/4.5 (different monitor content). Compensation for the first one is +3.99 now, for the second -2.17. The first one looks pretty overexposed while the second one looks very dark. If I change the sign to -3.99 the first and +2.17 the second one, brightness is similar, like in the other pair.

    Last I repeated the procedure with 2014May09.5D2212 (oldest on builds.magiclantern.fm) with slightly worse results than the 2013 version: First image 0.5s f/4 +0.68EV, second image 1/40s f/4,5 +1,65 EV

    The only commit in between was ef391df.

    However, I still suspect I have a fundamental error in my expectations due to a lack of understanding how exactly the module works...

  9. Alex

    Just tested on 5D3, with latest codebase. Two test images of the same static scene.

    • First image - 1/50s iso 3200 f1.4 => +2.34 EV
    • Second image - 1/100s iso 3200 => +3.23 EV

    That means, the sign is correct, and after applying the exposure compensation, both images look pretty much the same.

    However, on 5D2, this issue was reported recently, but I wasn't able to check it myself yet (I'm not home). http://www.magiclantern.fm/forum/index.php?topic=16157

    Are you getting correct raw zebras and raw histogram on your camera?

  10. Erik Krause reporter

    Histogram and zebras seem ok so far (if it is ok that the linear histogram is pretty low if there are overexposed areas in the image).

    I did the same test as you described with the same results: First image f/5.6 1/5s -0.54EV, second image f/5.6 1/10s +0.45EV look the same with applied compensation. This indicates that my expectations (and my understanding) where wrong and the code is ok. Sorry for the hassle!

  11. Alex

    "if it is ok that the linear histogram is pretty low if there are overexposed areas in the image" -> no, that's not OK.

    Do you mind testing older builds to find out when the histogram stopped working?

  12. Erik Krause reporter

    It seems to work this way already in ML 2013Jun29.5D2212. Log histogram is reasonably high but if I switch to linear it rises hardly above the base line if there are large overexposed areas. This is the case for both RGB and Luma histogram. If I change the exposure it is highest with least underexposed and least overexposed areas. If I move further to underexposure it becomes lower again. The Simplified HistoBar works as expected. Interestingly the non-RAW histogram shows the same for overexposure only, while the peak at the left side remains high for underexposure.

  13. Alex

    Ah, understood - so the issue is that the last bar is just invisible, but it's computed correctly.

    However, the issue I was talking about was outside LiveView (after taking a picture). Can you also take a screenshot outside LV?

  14. Log in to comment