[DONE] RAW overexposure warning

[l_d_allan]

I've found the RawDigger utility to be very informative during post processing for taking a close look at whether one or more of the RGBG channels has been blown out.

IMO, A "Raw Histogram" or "RAW blinkies" would be a terrific addition to ML, but my speculation is that providing the maximum RAW value might be more do-able for ML developers, and provide much of the value.

For my 5d2, a blown channel seems to be indicated with any channel having a value of 14737. I'd appreciate something as basic (if possible) as something like:
MaxRAW=#####

[Francis]

We are still restricted by the JPEG previews generated in camera to supply exposure info. The is UniWB, which gives a closer approximation for the histogram, and zebras with adjustable clipping points.

[a1ex]

Well... if you know what part of the image is overexposed, you can easily show the blinkies. And if you have access to raw data, you can compute the histogram too.

I have some ideas that might help with the blinkies part (JPEGs developed with -2 EV of digital ISO might be helpful).

Edit: yep, it's working on 5D2. For the impatient: MEM(0xc0f08030) = 500 in shootspy.c, stateobj_spy, and disable vignetting in Canon menu.

[a1ex]

Will be in tomorrow's nightly (5D2 only for now). It's quite tricky to use, and will underexpose the JPEGs by 2 EV.

Don't use it for serious stuff; I've just noticed that it alters the RAWs too, not just the JPEG preview. It will remove 2 bits of color depth. Was too good to be true

Quick HOWTO:
- Turn off peripheral correction.
- It needs calibration. Take a completely overexposed picture - it's used to compute the clipping points on the underexposed jpegs.
- Recalibrate every time you change pic style or white balance (but since you shoot RAW, you shouldn't need to change these).
- Use RGB zebras and histogram (the Luma ones won't work).
- Quick check: for overexposed pictures, the histogram peaks should align with the markers (if it looks strange, recalibrate).

Here's how it should look like:


And here's a sign that you should recalibrate (different WB, the peaks are no longer aligned):


Source code: https://bitbucket.org/hudson/magic-lantern/commits/174e18a5c3e5

[1%]

Doesn't seem to work on digicV. Also using the direct pointer which was 76094 seems to know if image is overexposed or not but gives the Take the pic with RAW blinkies ON error just like "real" state object below.

Code: [Select]

sub_39B50(aScsstate, 0x0, 0xffa26b2c: pointer to 0x1, 0x15) => ret_sub_39B50_FF15558C
*0x76098 = ret_sub_39B50_FF15558C

Here is 600D if anyone wants to try.

Code: [Select]

CreateStateObject(name='SCSState', 0x0, addr=0xFF5C4BBC, inputs=20, states=12) => ret_CreateStateObject_FF085714
aAJ_0x3164_SCS_0x00_to_0x0C.off_0x4 /*0x34B0*/ = ret_CreateStateObject_FF085714


[Audionut]

Is there anyway to hack the RAW>JPG feature to access the RAW files?

Very accurate overexposure warning in the field would be great.

[ItsMeLenny]

Here's how it should look like:


And here's a sign that you should recalibrate (different WB, the peaks are no longer aligned):

Is this right? As raw the colours wouldn't change depending on white balance.
It would depend on scene. However, due to the bayer sensor pattern, the green would always be higher than the blue and red no? (Unless there is no green in the scene).

[a1ex]

It's right, green clips first. It's not true raw histogram, only the clipping points are correct.

[a1ex]

Preliminary conclusions:

- digital ISO affects the RAW data.

- it's not possible to leave the RAW unaltered and underexpose only the JPEG. Here's why:

Code: [Select]

SCS  :(6)  --  5 scsCapReady         -->(10) // digital ISO is overriden here
...
SDSf3:(0)  --  3 sdsMem1toRAWcompress-->(1) // RAW and JPEG are developed from the same memory area (MEM1)
SDSf3:(1)  --  3 sdsMem1toJpegDevelop-->(1)

- it might be possible to find MEM1 and build histogram on the RAW data when taking the picture

- highlight warnings can be used in LiveView (we can underexpose the preview there without altering the final image)

- it's possible to adjust ISO in very fine increments => flicker-free bulb ramping possible?

More info: http://www.magiclantern.fm/forum/index.php?topic=1915.msg23797

So... I'll disable this feature for now, but research continues. I'll try to make the warnings usable in LiveView only (non-invasive, and better than nothing).

The current (invasive) method can be still used if you are willing to throw away 2 bits of color depth and compile a custom dcraw/ufraw with modified clipping points (just divide them by 4). Worth the hassle?

[Audionut]

Digital ISO affects the RAW post capture, correct?  ie:  It's just doing what you can do in post process at the expense of dynamic range.

For me personally, I wouldn't be bothered about the loss of color depth as I would only use it to find the settings that allow me to ETTR as much as possible.  Once the shutter, aperture and ISO are dialed in, then shoot as normal.

If you find MEM1 and get access to RAW, I would love the ability to limit zebras to each color channel.  This way, if your highlights don't contain a significant amount of details, you can clip the green channel by around 1EV before clipping either of the red or blue channels clip.  Giving you and extra 1EV of headroom that can be restored in your favorite RAW convertor.

[garry23]

All

There has been a lot of posting in the CHDK community on quasi-RAW histograms, that is giving the user a higher bit depth histogram, ie beyond the JPEG 8 bits.

The result is that I can now use Shot_histogram and inspect, say, the high end. The way the scheme works is that the algorithm lays down a sampling field and creates a sampled histogram, of defined bit depth, from the image.

As I say, it is not a true RAW histogram, but it is of higher fidelity that the 'native' one.

The downside is that it takes on-camera processing time, however, for its main use this is not so important. For example, I use it in am auto bracketing script as well as an ETTR script. It also has uses in timelapse scripts, eg bramping decision making.

Bottom line, the CHDK approach is not a RAW histogram, but it certainly seems to work for my scripts.

The above is just and observation and not a request.

[a1ex]

Idea: load a stripped-down dcraw as a module and run it on the CR2.

Problem: building the RAW histogram takes 3 seconds on core 2 duo (1.5s with O3). How long it could take on ARM? 30 seconds?

[Audionut]

30 seconds is better then removing the card, or connecting camera to computer to double check highlight detail.

Might find someone along the line with good ARM assembly knowledge who can speed it up in the future.

[l_d_allan]

So... I'll disable this feature for now, but research continues.

Thanks for taking an interest in this. Some of the info in the posts above was over my head.

My impression is that ML doesn't really have access to the RAW sensor data, but only the JPEG preview info. I'm a bit surprised by that, but the inner workings of the firmware are a mysterious black box to me.

My experience is that I haven't really been able to reliably count on the jpeg-based blinkies for ETTR "in the field". I've played with UniWB quite a bit, and find the green cast to be annoying. I've also tried using a "Picture Style" that starts with Neutral, and lowers Saturation and Contrast by -4. That seems to work about as well as UniWB, but still flawed.

BTW, my experience is that I can get a UniWB frame to base Custom WB on by either taking a "Black Frame" at 1/8000 with the lens cap on, or the opposite, aim at the sky and expose wide open for 2+ seconds to get a completely white, blown out frame. At least the Custom WB has a very green cast.

[l_d_allan]

30 seconds is better then removing the card, or connecting camera to computer to double check highlight detail.

To me, a RAW-based histogram that took 30 seconds to build would be well worth it. I'd turn that off for subsequent shots, after getting the ETTR exposure dialed in.

A lot of the pictures I take are panoramas, which tend to have a very high dynamic range. I'm trying to use HDR less and less.

[1%]

I can't even load modules on 6D with O only... bin is too big.

[a1ex]

I've found the 14-bit RAW data, now trying to decode it. So... RAW histogram and zebras should work without too much effort for the last picture (not for the ones already taken, though).

The module system is not yet ready for low-mem cameras (need to strip all the TCC part and keep the elf loader only).

[1%]

Would be golden if the RSCmgr hack worked. I'll try my luck on M

[a1ex]

Alright, now you have true RAW histogram and zebras. 5D2 only.

To use, simply choose RAW in Canon menu and set histo/zebra to RGB. No new menus - it should just work.

https://bitbucket.org/hudson/magic-lantern/commits/115f297ac7c8

[g3gg0]

FINALLY

now we can add a .DNG module

[Audionut]

Alright, now you have true RAW histogram and zebras.

Sweet.

Is there any chance of limiting zebras to a specific color channel? 

[1%]

maybe I'll have better luck porting this one.

[l_d_allan]

Alright, now you have true RAW histogram and zebras. 5D2 only.

Wow, I'm impressed. I suppose I would need to install the "nightly build" to test this out?  Would it be better for this ML newbie to wait several days or a week or more so that more experienced ML users can test out? I'm not confident I could recover from a bricked 5dm2.

Hmmmm ... I suppose it is a bit more complicated that my original thinking. Adobe ACR 5/6 with Process-Version 2010 can do a pretty good job of "Recovery" if one or two channels aren't blown. My limited experience with LR 4.x is that PV2012 is even better at that "Recovery", especially if only one channel is blown out.

So .... my impression is that even if a RawDigger-like ML capability "in the field" reports that RAW sensor values are blown out, it may be a usable frame if one or two channels aren't blown. 

Or not? I may very well have a flawed understanding of how "Recovery" works.

[a1ex]

Yes, if the channels are not all blown out, you can recover the highlights.

Here's the difference between RAW and JPEG histograms:

RAW histogram:


JPEG histogram:


So.. the JPEG histogram says the blue channel is really blown out, but the RAW one says you can push the exposure to the right by 1 stop without any problem (or even 2 stops if you don't mind blowing the green channel a bit). Let's try 2 stops:



And, of course, the RAW looks just fine (to me) when developed at -1.5 EV. Except for the bottom-right corner where recovery didn't work.



Also notice that, on the RAW histogram, you can see the exposure difference as a simple translation (and you can count the EV from the grid).

P.S. I've used the Landscape picture style (default settings). With Neutral, the difference is not that big.

[Audionut]

I'm loving that RAW histogram.  Exciting times.

For anyone following and wondering what the hell ETTR (Exposure to the Right) is, and why bother.  There is a thread over at POTN that is worth reading http://photography-on-the.net/forum/showthread.php?p=8534003#post8534003.

The 2 main reasons are noise and color accuracy.

Lets take this scene metered in evaluative metering at ISO 1600 to demonstrate the noise aspect.  All shot on a 5D3.




Quite a difficult scene for evaluative metering, and with the center of the shot over the sky, the camera is going to under expose.
Here are some 100% crops.  Each has only had chroma noise reduction and exposure adjustments.

Below is the shot as the camera exposed (ISO 1600, f/10, 1/4000) with 1.5EV (stop) increase in post.

The noise is predictably poor in this shot.  A combination of the camera under exposing and having to increase EV in post.

Below is ISO 1600, f/10, 1/1600. +0.3EV in post.  (note:  I did my sums wrong and should have only increased by 0.15EV)

Here is a shot exposed almost correctly.  The noise is much better in a correctly exposed shot

Below is ISO 1600, f/10, 1/640. -1.0EV in post.  (note:  It's to early in the morning to do EV corrections, but it's within 0.3EV and close enough

Here is a shot where I ETTR in camera.  That's ISO 1600!  Noise is basically non-existent all thanks to ETTR.

The other reason to ETTR, is color accuracy.
Take a look at the Full CS (Full Color Sensitivity) results for the 5D3 at DXO.
http://www.dxomark.com/index.php/Cameras/Camera-Sensor-Database/Canon/EOS-5D-Mark-III

Set the ISO to 100 and the Luminance to 30.
The black boxes represent what the color should look like.  And the white outline represents the range of colors that the camera actually reproduces.  Now select the luminance 50 and 70.  As we go higher up in luminance that the camera captures (further to the right on the histogram), the color accuracy improves.  As the color accuracy improves from luminance 30 through to luminance 70, it's only reasonable to assume that the color accuracy continues to improve through luminance 80, 90, 99, although there are no test results to back this assumption.

So once you have a full understanding of the benefits of ETTR, it's becomes easier to understand why accurate exposure information (histogram) in camera is so important.  Especially when you consider as a1ex has shown above, you can actually over expose the green channel on most occasions and still retain detail in your highlights.


edit:  The ETTR shots can often look less sharp thanks to the reduction in noise.  Noise does a good job of fooling our eyes into thinking there is more detail then there actually is.

Here are the CR2 files used in the above example.
https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/_46A5805.CR2
https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/_46A5809.CR2
https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/_46A5813.CR2