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=#####
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.
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.
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 :P
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:
(http://a1ex.magiclantern.fm/bleeding-edge/rawhisto-ok.png)
And here's a sign that you should recalibrate (different WB, the peaks are no longer aligned):
(http://a1ex.magiclantern.fm/bleeding-edge/rawhisto-bad.png)
Source code: https://bitbucket.org/hudson/magic-lantern/commits/174e18a5c3e5
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.
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.
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
Is there anyway to hack the RAW>JPG feature to access the RAW files?
Very accurate overexposure warning in the field would be great.
Quote from: a1ex on April 15, 2013, 08:44:05 PM
Here's how it should look like:
(http://a1ex.magiclantern.fm/bleeding-edge/rawhisto-ok.png)
And here's a sign that you should recalibrate (different WB, the peaks are no longer aligned):
(http://a1ex.magiclantern.fm/bleeding-edge/rawhisto-bad.png)
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).
It's right, green clips first. It's not true raw histogram, only the clipping points are correct.
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:
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?
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.
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.
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?
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.
Quote from: a1ex on April 16, 2013, 09:06:12 AM
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.
Quote from: Audionut on April 16, 2013, 11:01:02 PM
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.
I can't even load modules on 6D with O only... bin is too big. :(
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).
Would be golden if the RSCmgr hack worked. I'll try my luck on M
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
FINALLY :)
now we can add a .DNG module ;)
Quote from: a1ex on April 17, 2013, 11:43:04 PM
Alright, now you have true RAW histogram and zebras.
Sweet.
Is there any chance of limiting zebras to a specific color channel?
maybe I'll have better luck porting this one.
Quote from: a1ex on April 17, 2013, 11:43:04 PM
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.
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:
(http://a1ex.magiclantern.fm/bleeding-edge/raw.png)
JPEG histogram:
(http://a1ex.magiclantern.fm/bleeding-edge/jpg.png)
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:
(http://a1ex.magiclantern.fm/bleeding-edge/raw+2.png)
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.
(http://a1ex.magiclantern.fm/bleeding-edge/raw+2-dev.png)
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.
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 (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.
(https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/scene.jpg)
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.
(https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/under.jpg)
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)
(https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/correct.jpg)
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 :))
(https://dl.dropboxusercontent.com/u/34113196/Camera%20stuff/over.jpg)
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
I think many ML supporter are eagerly waiting a raw histogram in LV.
One, most probably silly, thought is could ML be used to provide the user a overexposure warning in the view finder?
My thought was that ML could high jack part of the canon display, for example could ML be used to flash the exposure indicator? Or one of the other canon display figure to give an unambiguous warning to the user that the raw histogram is clipping?
As I say, most probably a silly thought.
ML can't detect overexposure unless you are looking at the image review screen.
Thanks for the clarification, I should have worked that out for myself!
After some quick tests, RAW histogram and the zebras are matching exactly what I see from RawDigger :)
Sweet!
This is absolutely fantastic. You guys are amazing.
Hi guys,
First post.i have installed the nightly build to my 5D MKIII and I want to know how to enable the raw histogram.From what I have read you pick from canon menus to shoot raw,and then you pickup rgb histogram from ML menus.Is this correct?Also how you get an indication of a clipped channel?I see some numbers in the RGB histogram.
Thanks
There's no nightly for the 5D3 yet...
I followed these instructions :
So, I haven't seen any clear instructions for how people can try out the (unstable) development release yet (instead of the older Alpha 3), so here's my guide. Because it is an unstable development release, it could wreck your camera, so do this at your own risk. Please correct me if I get any of this wrong.
1. Start by updating your camera's firmware to the latest Canon version (1.1.3).
2. Because this isn't a final release, your camera needs a little modification made to it so that it can load Magic Lantern from the SD card. This is called turning on the camera's bootflag. When the bootflag is turned on, and a bootable SD card is inserted, the camera will load and run the file "autoexec.bin" from the SD card. Here, autoexec.bin will be the Magic Lantern software.
To turn on the bootflag, format your SD card in your camera, then copy this file to the root of your card:
http://a1ex.magiclantern.fm/bleeding-edge/5D3/5D3-113-bootflag.fir
Put it back into your camera, then run the firmware update option from the menus. The update will turn on your camera's bootflag.
3. Download the nightly Magic Lantern zip here. Unpack the zip file and copy just the "ML" folder to your SD card. Delete any .fir files that are on the SD card. You've now copied just the fonts and other data that ML needs to operate to your SD card.
4. Now you can copy a Magic Lantern development build (autoexec.bin) to the root of the SD card. Building this file is tricky, but NerveGas has kindly built a copy for us and posted it here. Unpack that zip file and copy the autoexec.bin to the root of your SD card.
5. You should now have an "ML" folder and an "autoexec.bin" file in the root of your SD card. That's the data/fonts and the actual Magic Lantern software. All that is left now is to set the "bootable" flag on the SD card, which tells the camera that it should look for and run the autoexec.bin file for us.
On Windows, you can use the EOSCard utility to do this:
http://pel.hu/eoscard/
Select your SD card, tick the EOS_DEVELOP and BOOTDISK options, install no FIR files, and Save.
On Linux / OSX, you can use the make_bootable.sh script instead. Plug in your SD card, then run the script from the terminal with sudo ./make_bootable.sh . Hopefully you know how to use the terminal.
6. Okay, so now you have the bootflag turned on in your camera (so it looks for bootable SD cards), you've marked your SD card as bootable, and you've copied the development Magic Lantern build "autoexec.bin" and the Magic Lantern data files "ML" to your SD card, you're ready to go! Turn off your camera, put the card in, and turn the camera back on. It should boot and run Magic Lantern.
Note: The nightly builds available on the main site do NOT support the 5D Mark III yet. You need to build autoexec.bin yourself or use the version provided by NerveGas instead (as these instructions already mentioned .
It works.Did i do something wrong?
Quote from: ouuzi on April 26, 2013, 04:18:49 PM
It works.Did i do something wrong?
Apparently not. You still are probably not running the newest version even with that autoexec.bin supplied by the other user. To get up to date code you have to compile for yourself. Look for help with that under the stickied post 'Getting Started with Development' under General Development Discussion.
Quote from: a1ex on April 17, 2013, 11:43:04 PM
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.
Several comments (sorry for the possible tl:dr ... and the SMF forum s/w "list" doesn't seem to be working):
- ** I installed the 2013-April-24 nightly build ... bit of a glitchy install ... had to pull battery / restart 5dm2 two or three times to get it to come back alive ... so this ML newbie has been hesitant to test beyond checking the version number to confirm installation.
- ** I'm unclear just how to get the RAW histogram in effect. I infer from the above that selecting RAW in the Canon menus and also RGB in the Canon menu for histograms would make this happen? This ML newbie is confused by the mention of zebras (which I haven't used yet).
- ** Perhaps the default "it just works" shouldn't be to have RAW histograms? Based on the "principal of least astonishment", having RAW histograms is significantly enough different ... imo ... to the Canon default that perhaps it should be an intentional choice? Rather than a silent behind-the-back choice made by ML? Plus I think it gives greater visibility to a what I feel is an impressive plus of ML for people considering using ML? Especially if they've wrestled with the hassle of UniWB?
- ** Or not so much astonishment? I may be like most DLSR users that assumed that blinkies/histograms are based on JPEG data when JPEG selected, and RAW data when RAW selected. I supposed I was astonished (unpleasantly) when originally trying to use ETTR that the histogram/blinkies were always based on the JPEG engine.
- ** Which brings up the question/complication: are "blinkies" based on RAW, or remain based on JPEG even when shooting RAW? If JPEG, you almost might want to disable "blinkies" when RAW histograms are in effect to avoid confusion/astonishment. Especially if RAW histograms are displayed when shooting in RAW, but the blinkies remain JPEG based.
- ** In any case, my impression is that it is a terrific accomplishment to get RAW histograms working. Well done!
- ** But in perspective, it would perhaps seem not that complicated for Canon to implement this, with their in-depth knowledge of the "inner black box". But I suppose that applies to a great deal of ML? I wonder if the "out of my budget" pro-level 1DX has RAW histogram/blinkies?
Quote from: Audionut on April 23, 2013, 12:59:56 AM
After some quick tests, RAW histogram and the zebras are matching exactly what I see from RawDigger :)
I infer that this would be the "gold standard test" that the RAW histograms were working?
Quote from: Audionut on April 23, 2013, 12:59:56 AM
After some quick tests, RAW histogram and the zebras are matching exactly what I see from RawDigger :)
My understanding is that using the desktop RawDigger utility would be the "gold standard test" ... it's indication of blown highlights and ETTR should correspond closely to what shows on the camera LCD? And the blinkies (if they are also based on RAW data)?
My further understanding is that use of the ACR histograms would be less accurate, as so much is going on that adjusts the pixel values (contrast, noise, sharpening, tone curves, etc). It gets more complicated because ProcessVersion 2003 is pretty good at Recovery, PV2010 may be better, and PV2012 is even better at Recovery, as long as all RGBG channels aren't saturated.
As noted in another post, this overwhelmed ML newbie is unclear just how to get the camera set so that RAW histograms are in effect. Sorry.
I suppose you could tell RAW histograms were operational by setting up a static, high contrast situation (using tripod?) and switching back and forth between having ML on, and having ML off. Or switching between RAW and JPEG in the Canon menus while ML was active? Correct?
My impression is that when in JPEG shooting mode and the histogram curve is just before the right-hand-side, a switch to RAW in the Canon menus would show the curve before the right-hand-side to a greater or lesser extent, but definitely a noticeable difference. Correct? Or do I again have a flawed understanding?
And a even more newbie question from someone unfamiliar with "zebras" ... can "zebras" be thought of as similar to "blinkies"? Or perhaps "smarter blinkies" that give more indication of "how much blown"? Rather than just "on / off" like blinkies?
Quote from: l_d_allan on April 26, 2013, 07:19:12 PM
Several comments (sorry for the possible tl:dr ... and the SMF forum s/w "list" doesn't seem to be working):
I installed the 2013-April-24 nightly build ... bit of a glitchy install ... had to pull battery / restart 5dm2 two or three times to get it to come back alive ... so this ML newbie has been hesitant to test beyond checking the version number to confirm installation.
You don't have to "install" anything. Just copy the new autoexec.bin onto the card replacing the old one.
Quote from: l_d_allan on April 26, 2013, 07:41:02 PM
My understanding is that using the desktop RawDigger utility would be the "gold standard test" ... it's indication of blown highlights and ETTR should correspond closely to what shows on the camera LCD? And the blinkies (if they are also based on RAW data)?
RawDigger is analyzing The captured RAW file on a PC. It has nothing to do with the camera LCD or anything else. Since it's accessing the RAW data directly (and not applying any post processing, tone curves etc), it's the most accurate.
Quote from: l_d_allan on April 26, 2013, 07:41:02 PM
My further understanding is that use of the ACR histograms would be less accurate, as so much is going on that adjusts the pixel values (contrast, noise, sharpening, tone curves, etc). It gets more complicated because ProcessVersion 2003 is pretty good at Recovery, PV2010 may be better, and PV2012 is even better at Recovery, as long as all RGBG channels aren't saturated.
Correct, ACR shows the histogram with all its processing applied. You can take a completely blown image and reduce exposure by 5EV and it will stop showing overexposure warning. Clearly, that highlight data is still gone though. What I have found though, is that ACR 2012 will not show the overexposure warning if it thinks it can recover the highlight data.
So RawDigger can show overexposure in the green channel (correctly), ACR will not, if it knows it can recover the detail from the other channels.
Quote from: l_d_allan on April 26, 2013, 07:41:02 PM
As noted in another post, this overwhelmed ML newbie is unclear just how to get the camera set so that RAW histograms are in effect. Sorry.
I suppose you could tell RAW histograms were operational by setting up a static, high contrast situation (using tripod?) and switching back and forth between having ML on, and having ML off. Or switching between RAW and JPEG in the Canon menus while ML was active? Correct?
My impression is that when in JPEG shooting mode and the histogram curve is just before the right-hand-side, a switch to RAW in the Canon menus would show the curve before the right-hand-side to a greater or lesser extent, but definitely a noticeable difference. Correct? Or do I again have a flawed understanding?
Canons histograms are based on the JPG preview that is generated for the LCD. This happens regardless of whether you are recording to JPG or RAW. Hence why there is UniWB and people using neutral profiles etc. Trying to get the JPG preview as close to the actual RAW data as possible. Same goes for Canon blinkies.
ML is now capable of accessing the RAW data directly. Hence, it's histogram and zebras are very accurate.
You have to be running the latest nightly and have RAW histogram and zebras enabled in the overlay menu.
Quote from: l_d_allan on April 26, 2013, 07:41:02 PM
And a even more newbie question from someone unfamiliar with "zebras" ... can "zebras" be thought of as similar to "blinkies"? Or perhaps "smarter blinkies" that give more indication of "how much blown"? Rather than just "on / off" like blinkies?
Zebras are MLs implementation of Canons blinkies. Same thing. Canons is based on it's JPG preview. ML can now base it's off RAW data.
So With that autoexec.bin file the RAW histogram is not enabled ?If i have to compile on my own is beyond my knowledge at the moment.Is a simple way to get raw histogram in the 5D III at the moment or i have to wait for a stable release?
The new RAW histogram is fantastic, it cuts a lot of guesswork out of getting the correct exposure and I will be using this feature heavily. Thank you! So far I've played around with it on my 5D3 and it seems to be working well. I especially like that it appears over the preview even if I'm viewing it fullsize. Up until now I've always found it frustrating that I couldn't see the (standard) histogram unless the image was just a small thumbnail in the top left. I would have to cycle through the 4 different display modes to review both the composition and the exposure.
Prior to now I've always used an "Image Review" setting of 2 seconds but now I'm finding 4 secs isn't enough either and I might need to set it to "hold" instead so I can take a good look at the raw histogram - it's much smaller than the standard histogram and takes my brain (and eyes!) a while to register what it says. Perhaps I'll get used to that in time though...
Something I noticed while reviewing a just-taken image. If I cycle to a different display mode via the "info" button, the RAW histogram immediately disappears :( Would it be difficult to keep it there for as long as the image was being reviewed, regardless of how many times info was pressed?
Further to that, I know it's a long shot (and non-trivial) but would it be possible to save the underlying histogram data that goes with each image (perhaps in a sidecar file, or a central DB)? Being able to see the raw histograms when reviewing older photos too would be incredible. If such a thing was possible then the code could be extended to store other Magic Lantern metadata too, opening up all sorts of interesting possibilities.
The one thing I can't quite figure out is that it's not clear to me what the numbers inside the R/G/B circles mean. I know the circles indicate a blown channel, is it a case of the higher the number the larger the area that is blown out?
Lastly, something that has been in the back of my mind for a while is for a way to get the camera to automatically calculate the best ETTR settings for you and take a shot based on that. There's an interesting article about exactly that here too: http://www.luminous-landscape.com/tutorials/optimizing_exposure.shtml (read the section titled "Welcome to the 21st Century"). Would it be possible for ML to take a test shot then calculate from the RAW histogram what the optimal ETTR exposure would be then immediately take another shot using the adjusted values? I can see this isn't always going to be easy, eg presumably there would need to be a threshold of sensels that were allowed to over-expose, and if the test shot was already beyond that then it might take a couple of iterations to find the correct lower exposure.
Would it be possible to write exif data or (even partial exif data) to the DNG files?
Yes, see chdk-dng.c
It looks like RAW histograms are not available when review time is set to 'Hold' due to the Ken Rockwell zoom trick.
It's been working fine here with it set to hold.
I'm using a 5d2 and when I have it set to 'Hold' the histogram doesn't say 'RAW' so I'm assuming it's jpeg based.
Yea, disable the zoom tricks. It only works in QuickReview, not in regular playback mode.
If you zoom at all histogram goes away... I think the raw data is lost? Ken rockwell zoom I think just takes you back to play mode when you zoom out.
Just pointing this out for anyone who might not be seeing it.
It's not lost, but as soon as you move to another picture, the data is no longer valid. So, the simplest check was to see whether we are in QR_MODE or not (since in QR you can't move to another picture).
Do the porting of raw overexposure detection will be ever available for the 550D and other models ? ::)
Ported to 600D but black level auto detect isn't working right.
Quote from: 1% on May 07, 2013, 03:27:29 PM
Ported to 600D but black level auto detect isn't working right.
I don't quite get this, maybe the answer is buried in some thread - will there be full raw support for older cameras like the 60d, i.e. overexposure/histogram & video?
Why not?
Quote from: a1ex on May 20, 2013, 04:56:11 PM
Why not?
I simply don't know if the raw stuff is doable on digic4 cameras (I didn't follow the development), and since raw video seems to be available only for newer digic5 cameras I was wondering if this is a coincidence or if it's not possible for 60d and the like...
Black level got fixed... working on many digic IV cameras... you just have to find the bins.
Hi,
It seems to me that files that are clearly not overexposed appear to be so with the RAW blinkies/zebras. The RAW histogram seems right though. In Lightroom, the raw file http://shayok.com/tmp/raw-hist/_MG_1799.CR2 requires only .25 stop underexposure in Process 2010 and none at all in Process 2012 to get all the highlights in the middle of the image. I got screenshots in ML, but unfortunately it doesn't capture the blinkies (VRAM0). VRAM1 and VRAM2 show my RAW zebra/hist settings.
http://shayok.com/tmp/raw-hist/VRAM0.BMP
http://shayok.com/tmp/raw-hist/VRAM0.422
http://shayok.com/tmp/raw-hist/VRAM1.BMP
http://shayok.com/tmp/raw-hist/VRAM1.422
http://shayok.com/tmp/raw-hist/VRAM2.BMP
http://shayok.com/tmp/raw-hist/VRAM0.422
I'm using magiclantern-v2.3.NEXT.2013Apr20.60D.550D.600D.50D.500D.5D2.1100D on 5D2.
I don't see any overexposure warnings in your screenshot.
As I said the blinking warning does not show up on the screenshot. Other than doing a video of the LCD, is there any other way of showing you?
If it's blinking, it's from Canon, turn it off...
Ah thanks!
Hi,
I'm a ML virgin but extremely keen to get a RAW histogram for use on my 5dIII. I do a lot of clean white interiors and mostly end up bracketing to get as good a ETTR exposure as possible, then sometimes use RawDigger to find the one closest to the right. I worry it looks a little unprofessional in front of clients and usually to a 'normal' exposure to give them an idea of what the finished image will be like.
I'll subscribe to the thread but just wanted to clarify where its at with regard to this functionality on the 5D III?
Jon
Quote from: sharperstill on June 29, 2013, 08:16:58 AM
I'll subscribe to the thread but just wanted to clarify where its at with regard to this functionality on the 5D III?
The [DONE] in the thread title is a pretty good hint ;)
if i disable the liveview and the review (because eats a lot of battery in a canon 7d)
will ETTR work in a timelapse?
Quote from: Audionut on June 30, 2013, 03:16:15 AM
The [DONE] in the thread title is a pretty good hint ;)
Sorry for re-opening this old thread.
Just wanted to express to A1ex and others:
The extraordinarily rapid development of RAW-based histograms/blinkies/zebras/etc (and then Auto-ETTR) is among the top two most impressive feats of software development expertise I've encountered in 45+ years of paid and FOSS s/w development. Beyond humbling.
Many years ago I was with Commodore Data as a Systems Manager for Commodore 64. When it died in the mid-90's I worked as a general journalist, but was of course interested in software developement. And I agree. The ML Universe is an outstandingly fine invention, done by a number of extremely well-skilled and innovative people. Way above and beyond the call of duty.
Agreed and I am actually loving the recent improvements made to RAW histogram ... This RAW OE warning is just icing on this fabulous cake! [emoji6]