Hi,
My question is about photo, not video.
I recently tried ML for the first time and I see it displays RAW histograms in live view. Unfortunately this doesn't help me to ETTR with studio strobes.
Is it possible to view raw histogram and or otherwise check for raw channel over/under exposure *after* taking the shot?
The camera is 5D3 in case that matters.
Overlay tab:
Global Draw ON, all modes
Histogramm RAW RGB, Log/Linear -> RAW EV indicator ETTR hint
RAW histogram visible in Image Review only. Not via Play button.
Thanks!
Is there anything else I need to set? It seems there is something wrong with these exposure indicators.
I see overexposure indication for image with max channel value 9200 (in RawDigger) but that is definitely far below saturation limit (which is about 11400 for 5D3). Why does ML show overexposure for image which is actually underexposed (not ETTR)?
It also seems these are not really raw because when I change the WB they change too.
I hope someone can clarify.
Here is an example which shows the difference between ML and RawDigger.
The image is correctly exposed to the right without clipping but ML shows that it is overexposed.
(https://snag.gy/WiMeHo.jpg)
CR2, please.
There it is:
https://goo.gl/5oCCW2
(http://a1ex.magiclantern.fm/bleeding-edge/raw/hist/over2.png)
On this image, ML assumes the clipping point at 9960 for ISO 160 and at 13200 for ISO 100. It doesn't know the true clipping point, which is not be the same across camera models and is affected by many factors, including exposure time and aperture (!), so it's trying to guess it from the brightest pixels in the image - raw.c:autodetect_white_level().
There are useful hints in this thread: http://www.magiclantern.fm/forum/index.php?topic=10111.0.
Thanks for looking at the file. BTW how were you able to view the histogram and overexposure indication? Walter previously said this is possible only during image review, i.e. only after taking the shot.
Quote from: a1ex on September 24, 2017, 12:52:05 AM
On this image, ML assumes the clipping point at 9960 for ISO 160 and at 13200 for ISO 100.
Where do these values come from?
Quote
It doesn't know the true clipping point, which is not be the same across camera models
I downloaded and installed ML 5D Mark III 123. How come a version specific for that model does not know the clipping points for it (considering also the factors you mention)?
Quote
and is affected by many factors, including exposure time and aperture (!), so it's trying to guess it from the brightest pixels in the image - raw.c:autodetect_white_level().
My test confirms that saturation values depend on these factors too but the values for ISO 160 are about 11400 in RawDigger which is quite far from 9960. Why is there such a huge difference?
My goal is to correctly ETTR, using the best of what the sensor is capable of, that's why I need correct feedback while shooting. Using this method (https://photographylife.com/riddle-intermediate-iso-settings) I have found that ISO multiples of 160 give slightly better DR compared to "native" ones. I also read your article (http://magiclantern.wikia.com/wiki/ISO) but I can't find a way to set those "best ISOs" which you recommend. How can I do it? (And is it applicable for photo at all?)
The article also says:
QuoteDial ISOs from ML menu/keys. ISO 160 from ML is better than ISO 160 from Canon controls.
but my test shows that there is no difference. Could you please explain?
Unfortunately using the standard Canon histograms (yes, with UniWB) can't give me accurate feedback - I always find a discrepancy between what they show and what RawDigger shows, so this results either in underexposure or overexposure. So I turned to ML hoping to be able to expose correctly to the right. But now when I see that the raw zebras are not really raw (they change when I change the WB setting) and that difference in saturation values which you explain - I wonder what to do.
What would you recommend to someone who needs correct raw ETTR for photo using the best of what the sensor is capable of?
Quote from: heyjoe on September 24, 2017, 03:54:19 PM
BTW how were you able to view the histogram and overexposure indication?
Very easy (http://www.magiclantern.fm/forum/index.php?topic=2864.msg174076;topicseen#msg174076) - I've emulated the image capture process in QEMU and used your CR2 as input data.
Quote
Walter previously said this is possible only during image review, i.e. only after taking the shot.
That's exactly what I did - on the virtual camera.
Quote
Where do these values come from?
From dbg_printf's from raw.c.
Quote
I downloaded and installed ML 5D Mark III 123. How come a version specific for that model does not know the clipping points for it (considering also the factors you mention)?
The findings from the ISO research thread are not yet included in ML, sorry about that. The code is generic; I was hoping to cover all ~15 (soon ~20) camera models with the autodetection.
In theory, the autodetected white level should be exact iff there are overexposed pixels in the image, or underestimated by about 0.3 stops in the worst case, if there is no overexposure. In tricky cases like this, I would have expected the white level to be assumed close to the brightest pixel, therefore the overlays showing very little overexposure (if any). That didn't happen, so I may need to re-think the white level heuristic.
Currently I don't know why the clipping point decreases at longer exposures (back then, when the white level was hardcoded, there was a bug about zebras no longer showing overexposure on long exposures - IIRC on 5D3). For aperture, I know how to find the digital gain and do the math, and I also know how to override it (see iso-regs.mo from the ISO research thread), but it's not implemented in the mainline.
Quote
My test confirms that saturation values depend on these factors too but the values for ISO 160 are about 11400 in RawDigger which is quite far from 9960. Why is there such a huge difference?
Probably the autodetection did not work well on this test image - will take a second look (just can't promise when, as this is a hobby project done on nights and weekends)..
The autodetection looks for some confirmation (it doesn't simply take the brightest pixel, as that one is likely a hot pixel and these can have values above the regular clipping point, at least on some models; don't remember if 5D3 is affected).
So yeah - it's not perfect, manpower is an issue and contributions are welcome.
QuoteI have found that ISO multiples of 160 give slightly better DR compared to "native" ones.
On recent models, they do - about 0.1 stops according to my measurements.
On older models (5D2 generation), they don't - they are the same.
http://www.magiclantern.fm/forum/index.php?topic=9867.0
QuoteDial ISOs from ML menu/keys. ISO 160 from ML is better than ISO 160 from Canon controls.
That's ancient stuff, long before we even had access to raw data in ML. I planned to write a newer version, based on the findings from the CMOS/ADTG thread, just never managed to complete it.
That means, most of that stuff actually applies to how Canon renders the raw data (i.e. picture styles). Back then, I've noticed a nicer highlight rolloff when overriding the digital gain from ML, rather than choosing an intermediate ISO from menu. Now I know there are a lot more parameters that change with ISO, and I've only understood a small subset of them.
When overriding digital ISO gain from ML, the other parameters will be inherited from the ISO selected in Canon menu. The same happens with dual ISO, and that's the reason ISO 100/1600 gives different results than ISO 1600/100.
Quote
but I can't find a way to set those "best ISOs" which you recommend. How can I do it? (And is it applicable for photo at all?)
Movie -> Image fine-tuning. Not applicable to photos.
BTW - are you interested in experimenting with the ISO research tools and hopefully reviving that thread? Most of that stuff applies to photos, and there is a significant DR improvement that can be achieved. You may start with the raw_diag and iso-regs modules, and maybe cross-check the results with other software.
Thanks for the detailed explanations. Sorry to repeat my main question but this is the actual thing I am looking for, I hope you can share some thoughts: :)
Quote from: heyjoe on September 24, 2017, 03:54:19 PM
What would you recommend to someone who needs correct raw ETTR for photo using the best of what the sensor is capable of?
Running ML in QEMU sounds really interesting. I am using KVM/QEMU to run guest OS's on my linux host, so I am curious to learn more about how to run ML too. Is the thread you linked to the thing I need to read? Or is there some sorted procedure?
Quote from: a1ex on September 24, 2017, 09:29:55 PM
Very easy (http://www.magiclantern.fm/forum/index.php?topic=2864.msg174076;topicseen#msg174076) - I've emulated the image capture process in QEMU and used your CR2 as input data.
That's exactly what I did - on the virtual camera.
It would be nice to be able to do it when pressing the Play button of camera. Is that possible to implement? Also is there a way to have bigger histograms? These look super small. I can't really imagine how I would get a visual feedback if I shoot in bright sunny day outdoors. Maybe we need a beep to tell us "It is overexposed"? :)
Quote
From dbg_printf's from raw.c.
I was rather wondering how they were determined before being put in your code, i.e. what physics they are based on and why they are so different from actuality.
Quote
The findings from the ISO research thread are not yet included in ML, sorry about that. The code is generic; I was hoping to cover all ~15 (soon ~20) camera models with the autodetection.
...
So yeah - it's not perfect, manpower is an issue and contributions are welcome.
I understand it is a work in progress. Of course I would be glad to help with what I can. However I am not a programmer per-se (I do some coding for simple scripts and web only). Is it really difficult to put the right saturation values and recompile? Or does it need more research in order to have them really accurate?
Quote
On recent models, they do - about 0.1 stops according to my measurements.
On older models (5D2 generation), they don't - they are the same.
http://www.magiclantern.fm/forum/index.php?topic=9867.0
Yes, I saw this thread which took me to the wikia article. My findings are in this spreadsheet (https://drive.google.com/open?id=11ShwsApXVoalXsI-Ly5pybjDKadWIqWBQ9LBZG834lc). It seems the difference is smaller than 0.1 stops.
Quote
Movie -> Image fine-tuning. Not applicable to photos.
Is it possible to make it available for photos too?
Quote
BTW - are you interested in experimenting with the ISO research tools and hopefully reviving that thread? Most of that stuff applies to photos, and there is a significant DR improvement that can be achieved. You may start with the raw_diag and iso-regs modules, and maybe cross-check the results with other software.
You mean the thread about iso160 multiples or? Please clarify what is your idea. I have been experimenting with RawDigger for the last few days, trying to answer my main question. If you think any test would help you to make ML do what I want - of course I would be glad to help.
BTW is it possible to program the sensor to capture light logarithmically and record it to raw data, instead of linearly? I mean not the log files which pop cameras output after converting raw data but to create/program a real logarithmic sensor. That would be a revolution. I have been searching for info about logarithmic sensors but the only one I found was about some CCTV cameras which have very high noise.
----
ETA: Why am I not getting any email notifications about updates on the thread? I have the following settings:
Turn notification on when you post or reply to a topic. = On (Instantly, for the 1st reply for replies and moderation).
Sorry I didn't include more links - my display is defective, so I am/was using a smartphone to mirror the main desktop (so I can type quickly, but reading or looking up links is slow).
First post from QEMU thread gives you a README.
CMOS/ADTG aka ISO research: http://www.magiclantern.fm/forum/index.php?topic=10111
Hardcoding clipping point: I know how to find it for short exposure times, but I don't know how it changes with long exposures. I only know it gets lower, from past bug reports, but didn't do a controlled experiment to find out by how much.
QuoteI was rather wondering how they were determined before being put in your code, i.e. what physics they are based on and why they are so different from actuality.
The white level detection is also explained in the iso160 thread. It starts from a low guess, then scans the image for brighter pixels, then backs off a bit - all this to make sure it shows the clipping warnings no matter what the correct white level might be. Your example case is either a bug or an edge case (didn't look yet).
In other words, I was just trying to come up with something that works on all other supported ML camera.
QuoteIs it possible to make it available for photos too?
Sure, but the digital gain will get burned in the CR2 (so you'll be losing levels without gaining additional highlight detail in the raw file). You will gain more highlight detail in the JPEG preview, but I don't see it a good enough reason to implement and maintain this "feature". Rather, the CMOS/ADTG tricks do actually capture additional highlights (effectively increasing DR), and that's currently available in the iso_regs module for 5D3 (just not very user friendly, but at least you can tweak all these sensor gains from the menu).
Quote
It would be nice to be able to do it when pressing the Play button of camera. Is that possible to implement?
https://www.magiclantern.fm/forum/index.php?topic=8309.0 (old answer)
https://www.magiclantern.fm/forum/index.php?topic=15088.msg186141#msg186141 (updated)
Quote
BTW is it possible to program the sensor to capture light logarithmically and record it to raw data, instead of linearly? I mean not the log files which pop cameras output after converting raw data but to create/program a real logarithmic sensor.
The closest approximation I can come up, besides dual ISO, would be this:
https://www.magiclantern.fm/forum/index.php?topic=19315.0
Alternating short/long exposures is doable, but not trivial. There are routines for doing arithmetic on raw buffers on Canon's image processor - documented here:
https://www.magiclantern.fm/forum/index.php?topic=13408.
If you can understand the sensor internals, you can probably change all its registers from adtg_gui. However, besides tweaking some gains at various amplifier stages, and overriding LiveView resolution to get 3K/4K/fullres LV, I wasn't able to find anything useful for controlling the clipping point beyond what's already documented in the ISO research thread. I'm not saying there isn't - I'm just saying I'm not familiar with sensor electronics, so maybe I don't know where to look.
There are some CMOS registers that appear to adjust the black sun protection, but didn't look much into them.
So, feel free to grab adtg_gui and understand/document what some of these registers do.
QuoteMy findings are in this spreadsheet.
It is my understanding that log2(max/stdev) is only a rough approximation, especially at high ISOs. Rather, I prefer to read it from the SNR curve - detailed answer: https://www.magiclantern.fm/forum/index.php?topic=13787.0
Also, how are you computing the noise stdev? There are many choices: from OB areas (not reliable, just an extremely rough approximation), from one dark frame (includes both fixed and random components), from the difference of two dark frames (you'll get the random noise component * sqrt(2), assuming it's Gaussian), or from the difference of two regular images (so you can estimate the noise at various signal levels - enough information for plotting the SNR curve).
For DR measurements, I have some confidence in raw_diag's 2-frame SNR analysis (a method inspired from Roger Clark's method); however, white level is still detected using heuristics (that may fail if the clipping is not harsh). For FWC and read noise, I have a feeling finding them from the SNR curve may be an ill-conditioned problem.
Quote from: a1ex on September 25, 2017, 07:35:40 AM
Sorry I didn't include more links - my display is defective, so I am/was using a smartphone to mirror the main desktop (so I can type quickly, but reading or looking up links is slow).
First post from QEMU thread gives you a README.
Thanks. I will look into it.
Quote
CMOS/ADTG aka ISO research: http://www.magiclantern.fm/forum/index.php?topic=10111
I already read this. My test confirms a slight improvement in DR after installing ML. Here are some calculated values and graphs showing the difference (diff = value_with_ML - value_before_ML):
(https://snag.gy/7UO2ih.jpg)
Quote
Hardcoding clipping point: I know how to find it for short exposure times, but I don't know how it changes with long exposures. I only know it gets lower, from past bug reports, but didn't do a controlled experiment to find out by how much.
The white level detection is also explained in the iso160 thread. It starts from a low guess, then scans the image for brighter pixels, then backs off a bit - all this to make sure it shows the clipping warnings no matter what the correct white level might be. Your example case is either a bug or an edge case (didn't look yet).
In other words, I was just trying to come up with something that works on all other supported ML camera.
What do you need to make it work accurately? I would be glad to provide test data if you don't have the time for it. Just let me know what I have to do.
Quote
Sure, but the digital gain will get burned in the CR2 (so you'll be losing levels without gaining additional highlight detail in the raw file). You will gain more highlight detail in the JPEG preview, but I don't see it a good enough reason to implement and maintain this "feature". Rather, the CMOS/ADTG tricks do actually capture additional highlights (effectively increasing DR), and that's currently available in the iso_regs module for 5D3 (just not very user friendly, but at least you can tweak all these sensor gains from the menu).
I am curious to try how it would work on photos but I don't find any module called iso_regs in the ML menu?
Quote
https://www.magiclantern.fm/forum/index.php?topic=8309.0 (old answer)
https://www.magiclantern.fm/forum/index.php?topic=15088.msg186141#msg186141 (updated)
Thanks. So it is the light button that does the thing.
BTW what is the reason for zebras to be affected by the WB setting? This means they are not really raw (although they are set to RGB RAW). Is that a bug?
Quote
The closest approximation I can come up, besides dual ISO, would be this:
https://www.magiclantern.fm/forum/index.php?topic=19315.0
Alternating short/long exposures is doable, but not trivial. There are routines for doing arithmetic on raw buffers on Canon's image processor - documented here:
https://www.magiclantern.fm/forum/index.php?topic=13408.
If you can understand the sensor internals, you can probably change all its registers from adtg_gui. However, besides tweaking some gains at various amplifier stages, and overriding LiveView resolution to get 3K/4K/fullres LV, I wasn't able to find anything useful for controlling the clipping point beyond what's already documented in the ISO research thread. I'm not saying there isn't - I'm just saying I'm not familiar with sensor electronics, so maybe I don't know where to look.
There are some CMOS registers that appear to adjust the black sun protection, but didn't look much into them.
So, feel free to grab adtg_gui and understand/document what some of these registers do.
I am not sure if we are talking about the same thing. The two links don't mention anything about logarithmic raw data. What I am talking about is not to look for a way to HDR but to use the actual DR of the sensor but instead of having it convert the light to linearly encoded data, to have the raw data in a logarithmic way. The advantages of that would be:
- No need for ETTR because we will have the same number of levels for any f-stop
- The benefits in post-production which follow that.
- Maybe even smaller raw files (because we don't really need 4000 levels per f-stop).
Of course that would also require customized raw conversion perhaps. I am getting the idea for this from a program called 3DLUTCreator (https://3dlutcreator.com/) which you may be familiar with. It has this unique functionality: when you open a raw file in it it
1) converts it to LogC.tiff (using Alexa's logc formula) which is 16-bit tiff with UniWB and logc encoded data
2) it works with that tiff to color grade it
This gives the possibility to encode the whole raw data into the LogC.tiff file (which can contain up to 21EV of DR) and also a fairly uniform number of levels per f-stop. (*fairly uniform - because they are not the same for each f-stop, due to the logc formula itself, it is not an ideal logarithm).
So all that got me thinking that if the raw file itself is logarithmic, that would probably save us from all the issues arising from the linearity of raw data today.
Your links reminded me of another thing though. Have you seen this:
https://www.nasa.gov/feature/revolutionary-camera-recording-propulsion-data-completes-groundbreaking-test
Quote
It is my understanding that log2(max/stdev) is only a rough approximation, especially at high ISOs. Rather, I prefer to read it from the SNR curve - detailed answer: https://www.magiclantern.fm/forum/index.php?topic=13787.0
I don't know why it should be a rough approximation. I am using this method as described by the libraw's developers. You can check the link which I gave, it describes it. I will look at your link too.
Quote
Also, how are you computing the noise stdev?
I don't know how exactly RawDigger calculates the sigma values. So far I have tried two kinds of dark noise samples:
1) from a shot with the lens caps on (used in the test to calculate the differences in the above graphics)
2) from the dark (hidden) pixel areas (recommended in the libraw developer's article, used in the Google spreadsheet which I shared in a previous post)
The difference between 1) and 2) is not very big. 2) seems to give more uniform values across channels while 1) seems to show bigger difference in DR between R, G, B, G2.
Quote
For DR measurements, I have some confidence in raw_diag's 2-frame SNR analysis (a method inspired from Roger Clark's method); however, white level is still detected using heuristics (that may fail if the clipping is not harsh). For FWC and read noise, I have a feeling finding them from the SNR curve may be an ill-conditioned problem.
I am not familiar with Roger Clark's method and I don't know what FWC is. Links?
So considering everything said so far:
Quote
What would you recommend to someone who needs correct raw ETTR for photo using the best of what the sensor is capable of?
:)
I also hope you can check why I am not getting any notifications about replies in the thread. I have them on in settings
QuoteI already read this. My test confirms a slight improvement in DR after installing ML.
You may want to double-check your test methods - with regular nightly builds, there is no change in DR at all.
QuoteI am curious to try how it would work on photos but I don't find any module called iso_regs in the ML menu?
Last time I checked, the search box was operational...
Roger Clark: http://www.magiclantern.fm/forum/index.php?topic=10111.msg117955#msg117955
QuoteHave you seen this:
https://www.nasa.gov/feature/revolutionary-camera-recording-propulsion-data-completes-groundbreaking-test
Yeah - want me to prepare that for next year's April 1st? :)
QuoteThe difference between 1) and 2) is not very big.
At least on the sensor used by Apertus, the difference is *huge*. On Canons... check yourself with raw_diag (in particular, at higher ISOs).
QuoteBTW what is the reason for zebras to be affected by the WB setting? This means they are not really raw (although they are set to RGB RAW). Is that a bug?
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Enough chit-chat for now.
Quote from: a1ex on September 25, 2017, 02:16:55 PM
https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Enough chit-chat for now.
That still doesn't answer my main question because obviously ML does not show the real raw histogram clipping. I provided all the info you asked for, so I don't see why this link. The 'chit-chat' arose from the fact that my main question was (and still is) unanswered. I won't repeat it again though. Thank you for your time.
You said:
Quote from: heyjoe on September 25, 2017, 01:45:05 PM
BTW what is the reason for zebras to be affected by the WB setting? This means they are not really raw (although they are set to RGB RAW). Is that a bug?
I'm not aware about such behavior, nor I can reproduce it, so it's your duty to provide some sort of proof. That was the reason for the link.
As for your main question, I'm afraid I don't understand it. What should I recommend?
On 5D3, at full stop ISOs, the autodetected white level can be underestimated by log2(15283-3000-2048) - log2(15283-2048) = 0.37 stops (worst case), iff there are no overexposed pixels in the image. So, you may get false clipping warnings within that limit. If that's good enough for you, then just use it.
Otherwise, for short exposures, you can override the digital gain to 512 with iso_regs (to disable aperture-related variations), then hardcode the white level to whatever raw_diag or raw_digger tells you (15283-1 for full stop ISOs), or maybe a few units lower if the clipping warnings are not there. For longer exposures, find out how the clipping point changes, write it down and find the pattern or some limits. For relatively slow lenses (such as f/2.8 ), you can ignore the effects of digital gain - just use the white level obtained with a manual lens. From f/4.0 and beyond, there's no more digital gain trickery.
However, hardcoding a bunch of camera-specific constants may quickly lead to a maintenance nightmare, so I'd prefer to either avoid it, or have some way to check their correctness - e.g. with this (http://www.magiclantern.fm/forum/index.php?topic=20560). That would require sample images at all the relevant ISOs, covering various exposure times and apertures, and from more than one camera, to ensure repatability; then integrating all this stuff in the test suite. Or, a way to fix the white level to some constant value (like 16000 or whatever) regardless of the other parameters (model-dependent, and the influence of exposure time is not yet understood).
Edit: looking through raw_diag sources, there is a register that appears to return Canon's white level (which probably ends up in the CR2 EXIF - didn't check that). It's the second number displayed by raw_diag:
int white = autodetect_white_level();
int canon_white = shamem_read(0xC0F12054) >> 16;
...
bmp_printf(..., "White level: %d (%d) ", white, canon_white);
Some values (autodetected by raw_diag vs Canon, manual lens, 5D3.123):
15283, 14582 (ISO 1600, 1/8" - off by 0.08 EV)
14090, 11995 (ISO 1600, 30" - off by 0.28 EV)
13307, 11388 (ISO 160, 1/8" - off by 0.27 EV)
13308, 10694 (ISO 160, 4" - off by 0.38 EV) [!]
12620, 10694 (ISO 160, 30" - off by 0.29 EV)
15284, 14582 (ISO 100, 30" - off by 0.08 EV)
Would that be a better approximation? If this trick works on other camera models, I'm tempted to use that instead of my autodetection (as Canon's heuristic does not depend on the image contents). My heuristic gives exact results if there are overexposed pixels, and underestimates otherwise; Canon's always underestimates by the amounts from the above table, regardless of whether the image is overexposed or not.
Do you have the patience to get a matrix of these values? You may use a Lua script if you wish.
FYI, the max values from your raw file are:
octave:1> a = read_raw('_MG_5911.CR2');
octave:2> prctile(a(:), [10 50 90 99 99.9 99.99 99.999 100])'
ans =
3353 8279 11886 12639 12848 12943 13006 13102
and here's how the clipping warnings would look with white level 11388 (Canon's heuristic for your settings):
(http://a1ex.magiclantern.fm/bleeding-edge/raw/hist/over3-white11388.png)
Quote from: a1ex on September 25, 2017, 04:41:53 PM
You said:
I'm not aware about such behavior, nor I can reproduce it, so it's your duty to provide some sort of proof. That was the reason for the link.
Obviously neither you, nor I are mind readers, so it would be easier if you ask directly to avoid misunderstanding. Anyway here is the proof:
1) WB set to UniWB:
In LiveView:
(https://snag.gy/MEWRy0.jpg)
After taking the shot:
(https://snag.gy/Mm3Vcw.jpg)
2) WB set to 5000K:
LiveView:
(https://snag.gy/ciqwFU.jpg)
After taking the shot:
(https://snag.gy/1msTFk.jpg)
As you can see:
- the zebras and histograms in image review are different for different WB
- the zebras in LiveView are different (histograms look the same) for different WB
- the zebras, histograms and values for the same WB are different in LiveView and in image review (Play > Light).
CR2 files:
https://drive.google.com/open?id=0B2Mb7hSVSnnFN3NuSkVVNjdRUTQ
Let me know if you need any more info about this.
Quote
As for your main question, I'm afraid I don't understand it. What should I recommend?
A way to correctly ETTR (even if it would mean not using ML).
Quote
On 5D3, at full stop ISOs, the autodetected white level can be underestimated by log2(15283-3000-2048) - log2(15283-2048) = 0.37 stops (worst case), iff there are no overexposed pixels in the image. So, you may get false clipping warnings within that limit. If that's good enough for you, then just use it.
I can get within that range without ML (using UniWB JPG histograms) but I am looking for something more accurate as the JPG histograms are really bad (I have tried so may variations in Picture style but still they don't show accurately the saturation).
Quote
Otherwise ...
Unfortunately I am not a programmer and if I dare to touch your code I am risking to damage something. As you correctly pointed out - this would be a maintenance nightmare and there would be more and more questions. That's why considering your much bigger expertise I was hoping that we can diagnose the issue together and hopefully you, knowing your code, could fix it properly (or advise for a way to correctly ETTR in a different way).
BTW I am thinking about another solution that may work for ETTR: Wouldn't it be much easier to simply display a zoomed portion of the rightmost zone of the raw histogram? Then one can simply evaluate by the shape of it (e.g. a spike) and see if there is clipping of a particular channel or not. In that case you won't need to detect or fix any values. It would be camera independent. All you would have to do is to display the portion of the histogram bigger and zoomed. What do you think?
Quote
13307, 11388 (ISO 160, 1/8" - off by 0.27 EV)
For which channel is that? Compared to previously mentioned max of 9960, this looks much closer to what RawDigger shows.
BTW in the spreadsheet which I shared (shot at ISO 160, 0.5") I notice a pattern in the saturation values (without black subtraction):
- for all ISO x160 multiples:
13519-13526- for all other ISOs and ISO 20000:
15518-15530- for ISO 25600:
16376Does that mean they are pretty much fixed (and can probably be hard coded?)
Quote
Do you have the patience to get a matrix of these values? You may use a Lua script if you wish.
I don't know Lua and I don't understand everything you do (I installed ML just 2 days ago). So please provide the steps for what you need me to do.
Quote
FYI, the max values from your raw file are:
octave:1> a = read_raw('_MG_5911.CR2');
octave:2> prctile(a(:), [10 50 90 99 99.9 99.99 99.999 100])'
ans =
3353 8279 11886 12639 12848 12943 13006 13102
and here's how the clipping warnings would look with white level 11388 (Canon's heuristic):
(http://a1ex.magiclantern.fm/bleeding-edge/raw/hist/over3-white11388.png)
I don't know why but RawDigger shows different values:
(https://snag.gy/8wpKgV.jpg)
and again according to RD this shot is a tad underexposed (considering RD's saturation at 11477) about 0.05EV. So if such overexposure is shown on LCD screen, that would make the photographer underexpose it even more which is contrary to ETTR.
Quote
- the zebras and histograms in image review are different for different WB
- the zebras in LiveView are different (histograms look the same) for different WB
- the zebras, histograms and values for the same WB are different in LiveView and in image review (Play > Light).
You are looking at YUV-based zebras. Try setting "Use RAW zebras: Always".
Also, when the histogram doesn't have vertical bars (stops), it's YUV-based.
QuoteWouldn't it be much easier to simply display a zoomed portion of the rightmost zone of the raw histogram? Then one can simply evaluate by the shape of it (e.g. a spike) and see if there is clipping of a particular channel or not. In that case you won't need to detect or fix any values. It would be camera independent. All you would have to do is to display the portion of the histogram bigger and zoomed.
Good point; however, I have some ideas to detect the presence of such a spike when checking the white level (a better heuristic). On Canons, the clipping is harsh (many pixels at the maximum value), with the possible exception of a few hot pixels.
Quote from: a1ex on September 25, 2017, 09:20:23 PM
You are looking at YUV-based zebras. Try setting "Use RAW zebras: Always".
I have "Use RAW zebras: Photo" and the help info says "Will use RAW RGB
after taking a pic". After reading your current reply I set it to "Always" but looking at the shots which I shared with Play->Light still shows different zebras and histograms.
Quote
Also, when the histogram doesn't have vertical bars (stops), it's YUV-based.
In Histogram type I have RAW-based (RGB) for which the help info says "Will use RAW RGB in LiveView and
after taking a pic"
Quote
Good point; however, I have some ideas to detect the presence of such a spike when checking the white level (a better heuristic). On Canons, the clipping is harsh (many pixels at the maximum value), with the possible exception of a few hot pixels.
Are you suggesting to simply wait for (the) next version?
See replies #1 and #11.
About hardcoding:
Adobe assumes a white level of 13100 for your CR2, and 15000 for most (all?) CR2's from 5D3 taken at full-stop ISOs. They get it wrong at long exposures (tested with Adobe DNG Converter 8.2 and 9.12). This shows they are not looking at Canon's white level tag (whatever that might be).
Dcraw/ufraw use 15488 (0x3c80) - obviously wrong (only correct at full-stop ISOs with fast apertures, and maybe some extremes like ISO 25600). They probably just took it from the first 5D3 sample they've got.
Rawspeed (used by darktable) has:
<Camera make="Canon" model="Canon EOS 5D Mark III" decoder_version="2">
<Sensor black="2060" white="15700" iso_list="400 500 1600"/>
<Sensor black="2060" white="15200" iso_list="100 125 200 250 800 2000"/>
<Sensor black="2060" white="15100" iso_list="2500 10000"/>
<Sensor black="2060" white="13700" iso_list="160 320 1250"/>
<Sensor black="2060" white="14200" iso_list="640 5000"/>
Unfortunately, these are not correct either.
If the white level used by the raw processor is higher than the true value, it will result in pink highlights; if it's too low, it will clip useful highlight detail (so, ideally it should be just a bit below the real value). Cross-check with:
15283 (ISO 1600, 1/8")
14090 (ISO 1600, 30")
13307 (ISO 160, 1/8")
13308 (ISO 160, 4")
12620 (ISO 160, 30")
15284 (ISO 100, 30")
Other raw processors likely hardcode their own values.
So, no matter what method we choose for white level, it probably won't match what most common raw processors will actually use, unless you override it manually with exiftool (after converting the CR2 to DNG). Besides, many raw processors use the wrong white levels, and the only workaround I know is to convert to DNG and set the white level manually.
(that was yet another can of worms I forgot about...)
Quote from: a1ex on September 25, 2017, 11:44:29 PM
See replies #2, #11.
Reply #1 is from Walter.
Reply #2 is from me.
If my replies are not counted, reply #2 is from you: "CR2, please"
If only your replies are counted, then I can't relate reply #2 (https://www.magiclantern.fm/forum/index.php?topic=20579.msg190334#msg190334) to anything regarding histograms/zebras discrepancies.
Considering that I can't be sure which is #11.
Please disambiguate.
I don't use ACR (I use libraw through 3DLC) and I am not looking to calibrate a perfect match between raw converters but:
Has what the raw converter assumes as white anything to do with correct ETTR? To my mind: As long as we can tune exposure in raw conversion for correct histogram of the output file it should not matter what the absolute values at the input are, so all that matters is right exposure. Or am I missing something?
ETA: You edited your answer, so I will have to add too:
What have histogram/zebras displayed as a visual feedback on camera LCD to do with raw converters? When you display the zebra/histogram you don't change the values in the CR2 file, you just compare them to a value and determine whether it must show as clipped or not. Right?
Typo - reply #1 (as printed by the forum).
Check the crop_rec_4k builds in a few hours.
Quote from: a1ex on September 26, 2017, 01:31:52 AM
Typo - reply #1 (as printed by the forum).
Thanks.
So if I understand correctly: the raw histogram and raw clip warnings show only in LiveView and in the instant image review (but not in Play+Light).
Unfortunately that doesn't explain why in LiveView the zebras are non-raw because it contradicts what one has set in the menu options:
Use RAW zebras = Always. I do read that the help info says "if possible" but it is not quite clear on what that "if" is based (and I couldn't find anything in the user guide). From a user perspective one should get what one has set in the menu.
I also think it would be useful to have an option in the menu to enforce raw histograms and clip warnings even in Play+Light menu. Can you do this?
Quote
Check the crop_rec_4k builds in a few hours.
It seems you have put the new heuristic in code which is great and I am curious to test it.
Do I simply download and unzip magiclantern-crop_rec_4k.2017Sep26.5D3123.zip onto the card? My concern is the warning on the top of the page:
"The following builds are works in progress, known to have rough edges.
Please test thoroughly before considering them for serious work."Are those crop_rec_4k less safe (potentially being able to cause damage)? Would you recommend to rather wait for the new functionality to be put in the main builds? I am just cautious not to damage my camera with something not fully tested.
In your LiveView screenshots, the histogram is raw; just double-check "Use RAW zebras" is really "Always". If that still doesn't give raw zebras, it's a bug, but I'm unable to emulate LiveView in QEMU yet. A video might be useful to figure out what's going on.
Safety-wise, they are about the same. These systems don't have a MMU, any task can write anywhere in the RAM, and Canon code saves their settings at shutdown by... reflashing the ROM.
The crop_rec_4k branch has an experimental safety check (https://bitbucket.org/hudson/magic-lantern/pull-requests/825) (as a bug there caused Canon settings to be overwritten on a few cameras, and a few of them did not boot as a result - luckily all recovered). That check will not prevent Canon code from writing garbage into the ROM (I still don't know how to prevent that), but will make it a little less likely to do so (by disabling their ROM reflashing after a crash, or when you take the battery out). So, until that safeguard gets into mainline, crop_rec_4k is *probably* a little safer.
In any case, the strongest safety net we have is the ability to emulate the firmware in QEMU (with the user's ROM), so if something goes really wrong (such as camera not booting or acting weird), I should be able to look into it. And, of course, the ROM dumper from bootloader (http://www.magiclantern.fm/forum/index.php?topic=16534.0).
Quote from: heyjoe on September 26, 2017, 10:09:31 AM
Would you recommend to rather wait for the new functionality to be put in the main builds?
Well, somebody *has* to test this before it goes into mainline :D
Quote from: a1ex on September 26, 2017, 10:53:51 AM
In your LiveView screenshots, the histogram is raw; just double-check "Use RAW zebras" is really "Always". If that still doesn't give raw zebras, it's a bug, but I'm unable to emulate LiveView in QEMU yet. A video might be useful to figure out what's going on.
Ok, I tested again (yes, RAW zebras is set to always). It seems zebras don't change on WB change in LiveView, only in Play+Light view. So if you can make Play+Light display raw histograms and zebras/clip warnings (or at least as an option) it would be great.
Quote
Safety-wise, they are about the same. These systems don't have a MMU, any task can write anywhere in the RAM, and Canon code saves their settings at shutdown by... reflashing the ROM.
Thanks for explaining.
Quote
The crop_rec_4k branch
... is *probably* a little safer.
You are doing a great job.
Quote
In any case, the strongest safety net we have is the ability to emulate the firmware in QEMU
I still haven't had the time to install that and try it out but I read that not only LiveView doesn't work in it but also Image capture and review without which I guess there is really nothing to test in QEMU, right?
Quote
(with the user's ROM),
What is that?
Quote
so if something goes really wrong (such as camera not booting or acting weird), I should be able to look into it.
How? What if my camera gets bricked and there is no way to diagnose?
Quote
And, of course, the ROM dumper from bootloader (http://www.magiclantern.fm/forum/index.php?topic=16534.0).
Is that something I *must* do before installing the crop_rec_4k build? Please explain as for a layman as this whole thing with so many links to different long threads is a little overwhelming for an ML newbie :)
Quote
Well, somebody *has* to test this before it goes into mainline :D
I would be happy to but of course I am cautious not to cause a damage.
Do I simply download and unzip magiclantern-crop_rec_4k.2017Sep26.5D3123.zip onto the card? Do I need to run "Firmware update" after that (as when installing ML for the first time)? Please provide the steps.
Thanks.
I can do this test for you if you still insist on it @heyjoe? The probability of bricking is extremely low and almost impractical to not give it a shot either way.
Quote from: DeafEyeJedi on September 26, 2017, 04:39:21 PM
I can do this test for you if you still insist on it @heyjoe?
That would be very nice of you. Could you please also explain how you do it? I.e. are you doing it in QEMU or in camera and how is the crop_rec_4k version to be installed?
Quote
The probability of bricking is extremely low and almost impractical to not give it a shot either way.
I suppose it is so but because I am very very new to ML I am extra careful (maybe extra paranoid too).
Quote from: heyjoe on September 26, 2017, 05:02:50 PM
That would be very nice of you. Could you please also explain how you do it? I.e. are you doing it in QEMU or in camera and how is the crop_rec_4k version to be installed?
Actually I do everything in Cameras. Wish I had gotten into QEMU sooner. Will do one day not only just for out of respect to @a1ex and crew but to help push things forward at a quicker pace. Anyway off I go to my test...
Just downloaded the latest experimental (9/26/17) for 5D3.123 and was able to turn on 'Always On' under 'Use RAW zebras' within the Overlay tab in ML menu. Took a photo and while in preview (mine's set to 4 seconds) there I can see the lovely ML Histogram but then once I press the 'Playback' button to preview the photo once more which doesn't show ML Histogram. Was I expecting (or at least I was hoping) to see this while in playback mode?
QuoteI suppose it is so but because I am very very new to ML I am extra careful (maybe extra paranoid too).
I don't blame you. Regardless of how many days you have been using ML I am impressed with your investigation so far and quite intriguing especially coming from a newbie if that's what you call yourself. I would say a heck of a newbie that's capable of pushing things forward overall as a whole.
'Don't just risk anything, take risk with everything' is one of my favorite motto's. :P
Also in case you were still curious on how I was able to download and install the experimental build. Very similar to the nightlies, if not the same to be exact.
Thanks @DeafEyeJedi!
Here is the result of my test: CR2 files (https://drive.google.com/open?id=0B2Mb7hSVSnnFa3ZTdTFaQ3d0R1U).
All images are @f/2.8. The screenshots are arranged left to right LiveView (LV), Image review (IR), RawDigger (RD).
ISO 160
0.6s
(https://snag.gy/aszq7e.jpg) (https://snag.gy/HsxlOf.jpg) (https://snag.gy/ueE0ZY.jpg)
0.8s
(https://snag.gy/0cmpzU.jpg) (https://snag.gy/smd6nH.jpg) (https://snag.gy/7PksT4.jpg)
1.0s
(https://snag.gy/NGTwfC.jpg) (https://snag.gy/z5YTSF.jpg) (https://snag.gy/a2d5Eu.jpg)
1.3s
(https://snag.gy/qB1Y3Z.jpg) (https://snag.gy/jwLC3f.jpg) (https://snag.gy/5Fck91.jpg)
ISO 100
1s:
(https://snag.gy/mai89t.jpg) (https://snag.gy/oZ1Epy.jpg) (https://snag.gy/nfCsbF.jpg)
1.3s:
(https://snag.gy/hvcYUt.jpg) (https://snag.gy/k0xQI9.jpg) (https://snag.gy/T2ufBZ.jpg)
1.6s:
(https://snag.gy/PiKY1w.jpg) (https://snag.gy/XbofOt.jpg) (https://snag.gy/zUbqHl.jpg)
2s:
(https://snag.gy/cPvaSG.jpg) (https://snag.gy/LgbvDN.jpg) (https://snag.gy/gn3OJC.jpg)
The closest to perfect ETTR shots seem to be:
ISO 160, 0.8s: RD shows overexposure of about 0.02EV, IR shows R=33, G=20 overexposure
ISO 100, 1.6s: RD shows overexposure of about 0.02EV, IR shows R=45, G=33 overexposure
Does this prove the new heuristic to be more accurate?
Disclaimer: the light in the room where I shoot may not be perfectly constant.
Nice test.
I'm unable to reproduce the black zebras - are they from Canon?
To capture the LiveView images, you may use Debug -> Dump image buffers (a 14-bit DNG and two 8-bit YUV422).
There's a screenshot option as well (no need to photograph the camera screen). It won't capture the fast (YUV-based) zebras well (as these are computed by the display controller), but should work fine with all other kinds of zebras (including the RAW-based ones). Your LiveView screenshots show YUV zebras.
Quote from: a1ex on September 27, 2017, 04:52:26 PM
I'm unable to reproduce the black zebras - are they from Canon?
Yes.
Quote
To capture the LiveView images, you may use Debug -> Dump image buffers (a 14-bit DNG and two 8-bit YUV422).
There's a screenshot option as well (no need to photograph the camera screen). It won't capture the fast (YUV-based) zebras well (as these are computed by the display controller), but should work fine with all other kinds of zebras (including the RAW-based ones).
Thanks for the tip. However sometimes it is easier to use my phone and just send the image via bluetooth instead of moving the card back and between the camera and card reader.
QuoteYour LiveView screenshots show YUV zebras.
My settings are (taken using the screenshot option):
(https://snag.gy/elVIoH.jpg)
So what did we learn from this test? Is there anything more that can be done regarding the accuracy of ML for ETTR? Or anything else to test?
It would be really great if the LV histograms are really raw and to have raw histogram/zebras in Play button too (not only in image review).
With the same zebra settings, here's how they look like here (LiveView vs QR):
(http://a1ex.magiclantern.fm/bleeding-edge/raw/hist/zebras-lv.png) (http://a1ex.magiclantern.fm/bleeding-edge/raw/hist/zebras-ph.png)
Note the LiveView RAW zebras have horizontal lines (not diagonal), they show the same color as the clipped channel(s) (or black if all channels are clipped) and they have "square" edges for speed reasons (they operate on a very low-res image). In QR (after taking a picture), speed is no longer an issue, so they are computed for every displayed pixel.
The Luma zebras (YUV-based) are diagonal red. The YUV RGB zebras also have horizontal lines, but thicker, and fully overexposed areas are solid black.
However, your LiveView histograms are RAW-based.
Can you upload your ML/SETTINGS directory so I can try to reproduce the issue?
Quote from: a1ex on September 27, 2017, 05:47:35 PM
Note the LiveView RAW zebras have horizontal lines (not diagonal), they show the same color as the clipped channel(s) (or black if all channels are clipped) and they have "square" edges for speed reasons (they operate on a very low-res image).
Thanks for explaining. It is possible that during the test I have had the settings to "Photo only". Now I tested again with "Always" and they are horizontal and unaffected by WB setting (histograms too).
ETA: But still LV and QR show different overexposure warnings.
Quote
In QR (after taking a picture), speed is no longer an issue, so they are computed for every displayed pixel.
Does that mean you can also make it to work in Play-button mode?
BTW there is an issue in QR mode. If previously (before taking the current shot) a picture was Played and with a few presses of the Info button it was set in a mode to display Canon's JPG histograms, ML's stuff overlays all that and the view becomes a mess. Example:
(https://snag.gy/mntxJc.jpg)
The rectangle on top left is the reduced image which Canon shows and right and below of which Canon's histogram and info display.
ETA: same with Play->Light.
Quote
The Luma zebras (YUV-based) are diagonal red. The YUV RGB zebras also have horizontal lines, but thicker, and fully overexposed areas are solid black.
However, your LiveView histograms are RAW-based.
Can you upload your ML/SETTINGS directory so I can try to reproduce the issue?
https://drive.google.com/open?id=0B2Mb7hSVSnnFVjV4RjFIMEZUb1U
Please explain what is needed to test further to improve the accuracy as it obviously still cannot be used for correct ETTR.
Also why the accuracy in ISO 160 is worse than that for 100?
Here is a proof that LV (RAW) zebras and histograms don't match those of QR (supposedly also RAW):
(https://snag.gy/9Vn3uT.jpg) (https://snag.gy/0OElS8.jpg)
QuotePlease explain what is needed to test further to improve the accuracy as it obviously still cannot be used for correct ETTR.
For me it's not obvious at all. Except for the lack of clip warnings at ISO 160 1" (which I'm looking into), I don't see anything wrong with the QR zebras.
On the affected image, clipping is not harsh, but looks like this:
octave:1> a = read_raw('_MG_6049.CR2', 1);
octave:2> prctile(a(:), [10 50 90 99 99.99 100])'
ans =
3638 10539 13473 13474 13474 13668
octave:3> imshow(a(1:8:end,1:8:end), [13460,13480])
(http://a1ex.magiclantern.fm/bleeding-edge/raw/hist/iso160-clip.png)
and that means I should imagine some other heuristic for detecting the peaks (ML used white=13664, above 13474).
octave:4>sum(a(:)==13473)
ans = 6856086
octave:5> sum(a(:)==13474)
ans = 1916444
octave:6> sum(a(:)==13475)
ans = 0
octave:7> sum(a(:)>13475)
ans = 987
The issue is those few pixels above the clipping point (in your case, "only" 987). I might have to build a real histogram for evaluating the white level.
The LiveView RAW overlays are not very exact, but not trivial to fix - let's figure out the QR ones first.
Quote from: a1ex on September 27, 2017, 06:40:39 PM
For me it's not obvious at all. Except for the lack of clip warnings at ISO 160 1" (which I'm looking into), I don't see anything wrong with the QR zebras.
I say obvious because:
ISO 160, 0.6s is quite underexposed. The maximum value in RD is far below saturation (~11400), perhaps about -0.55EV. QR shows R=4 and G=2 clipping for this shot (6047).
ISO 160, 0.8s is just 0.02EV overexposed in RD (R=12%, G=6.8%, B=0%, G2=6.7%). QR shows R=33, G=20 overexposure. Assuming that ML's values are % too, the difference is about 3 times.
etc.
Quote
and that means I should imagine some other heuristic for detecting the peaks
You can probably compare the size of the rightmost values in the histogram to those just left of it and if it is above a certain threshold that should indicate a clipping. That may work for the "OVER" indication in the histogram but how will you propagate it back to the image (zebras)? Sounds like computation consuming.
Quote
The LiveView RAW overlay are not very exact, but not trivial to fix - let's figure out the QR ones first.
Sure. QR is more important for photo.
Quote from: a1ex on September 27, 2017, 06:40:39 PM
The LiveView RAW overlays are not very exact, but not trivial to fix - let's figure out the QR ones first.
Quote from: heyjoe on September 27, 2017, 07:07:48 PM
Sure. QR is more important for photo.
Agreed.
Okay, found a histogram-based method that appears to work fine for the above samples (didn't check all of them, as conversion to QEMU format is still a bit of a hack).
The raw_diag module has a slower version of the same algorithm (it checks more pixels and prints some details on the console).
Also found the issue with histogram clipping warnings (it was considering one additional column from the histogram - about 0.1 stops - as overexposed).
Builds coming soon.
Great. Looking forward to it.
Please write when it is ready to test.
Take a look at the change log (https://bitbucket.org/hudson/magic-lantern/branch/crop_rec_4k) -> it is.
Thanks! I will test a little later and post results.
CR2 files (https://drive.google.com/open?id=0B2Mb7hSVSnnFSkZxZ1d3cmgxMEk)
ISO 160, 0.8s
(https://snag.gy/HnzfZe.jpg) (https://snag.gy/lAbjRz.jpg) (https://snag.gy/smKHaq.jpg)
ISO 160, 1s
(https://snag.gy/x0JwHi.jpg) (https://snag.gy/NoUnwE.jpg) (https://snag.gy/41SAXG.jpg)
ISO 160, 1.3s
(https://snag.gy/pa1fCO.jpg) (https://snag.gy/jRq3vI.jpg) (https://snag.gy/MfTCHr.jpg)
ISO 100, 1.6s
(https://snag.gy/OR6gdS.jpg) (https://snag.gy/ROgrin.jpg) (https://snag.gy/BOv9LV.jpg)
ISO 100, 2s
(https://snag.gy/VxOFel.jpg) (https://snag.gy/kqHD9p.jpg) (https://snag.gy/CAEij1.jpg)
ISO 100, 2.5s
(https://snag.gy/L0Wulo.jpg) (https://snag.gy/ZrtUHX.jpg) (https://snag.gy/YrKzgd.jpg)
The result in QR is almost perfect! Great work. The difference seems biggest in the G channel in ISO 160 shots.
There is some discrepancy in LiveView, perhaps due to different calculation.
Do you think you can make the raw ETTR warnings to work in Play mode?
ISO 100 1.6" is the only one obviously different - to me - from RawDigger. Taking a closer look:
octave:1> a = read_raw('_MG_6086.CR2');
octave:2> prctile(a(:), [0 1 10 50 90 99 99.9 99.99 99.999 100])'
ans =
2212 2865 3963 10080 14306 15215 15449 15464 15465 15471
octave:3> sum(a(:) == 15462)
ans = 332
octave:4> sum(a(:) == 15463)
ans = 381
octave:5> sum(a(:) == 15464)
ans = 14765
octave:6> sum(a(:) == 15465)
ans = 2072
octave:7> sum(a(:) == 15466)
ans = 0
octave:8> sum(a(:) >= 15467)
ans = 1
octave:9> imwrite(a(1:2:end,1:2:end) > 15463, 'clip-red.pgm')
(http://a1ex.magiclantern.fm/bleeding-edge/raw/hist/clip-red.png)
=> ML was right 8)
QuoteDo you think you can make the raw ETTR warnings to work in Play mode?
Asked and answered (http://www.magiclantern.fm/forum/index.php?topic=20579.msg190411#msg190411).
Additionally, if anyone does the "boring" part of parsing a CR2 to get the lossless JPEG payload (StripOffsets tag retrieved in C rather than with exiftool), I can do the rest (figuring out the current image in playback mode, decoding it...).
This is a very easy coding task, does not require any camera programming, just reading existing docs and source codes around the net (and time to debug it).
Quote from: a1ex on October 03, 2017, 10:55:41 PM
ISO 100 1.6" is the only one obviously different - to me - from RawDigger. Taking a closer look:
What does this code do? Looks like some statistical analysis but I can't grasp the details.
I see that ML shows significant overexposure G=29% for ISO 160 1" and G=58% for ISO 160 1.3" but in RD green is not overexposed. What is the reason for this difference? 29% and 58% is quite big. For ISO 100 the values are with not more than 1% difference from RD, so just like in the older test ISO 100 seems to work more accurately.
Quote
This is a very easy coding task, does not require any camera programming, just reading existing docs and source codes around the net (and time to debug it).
Can you provide links to the necessary docs? I am curious to see if I have completely forgotten to code in C (it's been many years) :)
Why RawDigger shows the numbers it shows, I have no idea.
octave:1> a = read_raw('_MG_6084.CR2');
octave:2> prctile(a(:), [0 1 10 50 90 99 99.9 99.99 99.999 100])'
ans =
2208 2856 3929 10107 13473 13474 13474 13474 13581 13683
octave:3> sum(a(:) == 13472)
ans = 2709
octave:4> sum(a(:) == 13473)
ans = 4543731
octave:5> sum(a(:) == 13474)
ans = 1371767
octave:6> sum(a(:) >= 13475)
ans = 663
octave:7> a_red = a(1:2:end, 1:2:end);
octave:8> a_g1 = a(1:2:end, 2:2:end);
octave:9> a_g2 = a(2:2:end, 1:2:end);
octave:10> a_blue = a(2:2:end, 2:2:end);
octave:11> sum(a_g1(:) > 13472) * 100 / prod(size(a_g1))
ans = 30.257
octave:12> sum(a_g2(:) > 13472) * 100 / prod(size(a_g2))
ans = 30.213
Hopefully the code is clear enough this time.
Don't be afraid to read the docs.
Thanks.
Quote
Don't be afraid to read the docs.
I am not and that's why I asked for a link. However all I find is the user guide and the Lua api doc which I suppose is not what you mean?
Click! (http://bfy.tw/EHGd)
Quote from: a1ex on October 04, 2017, 01:06:27 AM
Click! (http://bfy.tw/EHGd)
Obviously some misunderstanding. I thought you were talking about docs of ML. Nevermind. I am quite happy with what this thread has lead to. Hopefully after all the testing this code is ready to go into the regular versions :)
Before including the updated code in regular nightlies, may I ask for testing feedback from owners of the other cameras present in the crop_rec_4k builds? (700D, EOSM, 100D).
Reason: other sensors might clip to white in different ways, and the current heuristic makes a tight assumption: that the clipping point is harsh and spans on one or two levels (not more). I'm not sure whether this holds true on other camera models.
Quote from: a1ex on October 04, 2017, 05:55:09 PM
Reason: other sensors might clip to white in different ways, and the current heuristic makes a tight assumption: that the clipping point is harsh and spans on one or two levels (not more). I'm not sure whether this holds true on other camera models.
I don't know if this may help but here (https://www.youtube.com/watch?v=NdLjU70xhdQ) is a video about RD which mentions highlight histogram shapes (scroll to 2:40). The speaker says "A bell" shape is typical for Canon and also talks about the changing of saturation value at different exposure parameters (which you mentioned in an earlier reply).
Quote from: a1ex on October 04, 2017, 05:55:09 PM
Before including the updated code in regular nightlies, may I ask for testing feedback from owners of the other cameras present in the crop_rec_4k builds? (700D, EOSM, 100D).
Reason: other sensors might clip to white in different ways, and the current heuristic makes a tight assumption: that the clipping point is harsh and spans on one or two levels (not more). I'm not sure whether this holds true on other camera models.
Done. (http://www.magiclantern.fm/forum/index.php?topic=16040.msg191131#msg191131Done.)
Tested some long exposures (30 seconds at higher ISOs) - it no longer clips harshly, so my algorithm thinks the images are not overexposed (even when it's obvious to the human eye on the histogram).
Will push a fix shortly.
Quote from: a1ex on October 07, 2017, 11:20:15 AM
Will push a fix shortly.
Good. Please let us know if we need to test anything again.
Quote from: heyjoe on October 07, 2017, 12:16:22 PM
Good. Please let us know if we need to test anything again.
Test the latest code changes. Does the latest fix actually work? Did it brake something?
Test as if you are doing QC for a company (https://www.magiclantern.fm/forum/index.php?topic=12657.0).
Quote from: Audionut on October 09, 2017, 01:31:42 AM
Test the latest code changes. Does the latest fix actually work?
Where is it? Has it been published? What exactly is new to test?
Quote
Did it brake something?
I definitely prefer not to test for the purpose of answering this particular question. A non booting camera is the last thing anyone needs.
Quote
Test as if you are doing QC for a company (https://www.magiclantern.fm/forum/index.php?topic=12657.0).
I have been doing it so far. Not sure what you are implying.
Quote from: heyjoe on October 09, 2017, 02:34:58 AM
Where is it? Has it been published?
Here (https://bitbucket.org/hudson/magic-lantern/commits/all). Specifically here (https://bitbucket.org/hudson/magic-lantern/commits/5d2d8c186b8336ef592028cd44bc51040b0375a7) and here (https://bitbucket.org/hudson/magic-lantern/commits/11ab1f3ba4f1a1642fbcab955b6562666fea9bb8).
In that first link, on the right hand side next to the date, you can see that the fix was pushed to branches
crop_rec_4k and
iso_research, not the nightlies (unified branch). In other words, the semi-stable stable nightly build doesn't yet have the fix applied, because...........it needs people to test it first.
So, if you really want to help the project (no implications, simply statements (perhaps I should find a way to reword this statement)), the next (easy) step is to go here (https://builds.magiclantern.fm/experiments.html). If you have a 5D3, 100D, 700D or EOSM, yay, we have a winner, look at "
4K raw video recording; lossless compression". You will notice in the changelog for the latest builds there.
Raw backend: allow non-harsh clipping for white level
(should fix clip warnings at long exposures with high ISOs, e.g. 30" ISO 6400) So these builds have the latest code change applied.
If you don't have one of the above mentioned cameras, and still (really, really, really
*) want to help, then you'll have to learn how to compile the source code (http://www.magiclantern.fm/forum/index.php?board=25.0), compile the iso_research branch and test as if you were............ (http://www.magiclantern.fm/forum/index.php?topic=12657.0).
* If you really want to help, but cannot or will not follow the above, then sorry, you can't help. Maybe next time.
Quote from: heyjoe on October 09, 2017, 02:34:58 AM
What exactly is new to test?
The raw histogram.
a1ex has pushed some new code changes regarding the raw histograms, to fix an issue he noticed (while testing as if he was doing QC for a company) regarding high ISOs and long exposures. This code change may have fixed the issue, it may have only fixed the issue on his camera, it may have broken something else (maybe the histogram no longer works on a 6D). And so, to beat that dead horse, this needs testing as if..........
Quote from: heyjoe on October 09, 2017, 02:34:58 AM
I definitely prefer not to test for the purpose of answering this particular question. A non booting camera is the last thing anyone needs.
Whoa, slow down there. I didn't mean the latest fix might shatter your camera into a million pieces (although it may), only that the histogram might not even work any longer on your camera after this code change. The histogram might be broken. Maybe the histogram menu item no longer displays. Maybe some other minor little thing (that won't result in a non booting camera) might be broken. Someone needs to test this. You asked "Please let us know if we need to test anything again".
Quote from: heyjoe on October 09, 2017, 02:34:58 AM
Not sure what you are implying.
Most of the time we focus on something simple, or expect someone else to do all of the work, or maybe we just aren't entirely sure exactly how to help efficiently. So don't just take a single photo, observe that the histogram appeared to work, and call it a day. Test that sucker. Try and find a repeatable test case where the histogram doesn't work.
If you find something broken, good, tell a1ex while he's in the mood to play with this specific piece of ML code. If you don't find anything broken, even better, make sure you tell a1ex that also, as it will build his confidence to push this fix into the nightly builds so that everyone can enjoy the fruits of your work.
Most importantly, if my post offended you, go back and read it with a sense of humor. :D It's not personal. Perhaps you cannot help further, that's fine. But someone else quietly reading this thread may be able to help, and so the steps I have outlined may be useless for you, but...........
Audionut signing off, good day Sir.
Thanks for the clarifications. I just needed to know when the changes are complied and ready for testing as I still don't know how this whole system of development works.
Unfortunately I cannot test "as if doing QC test for a company" because:
- companies testing all possible scenarios provide the necessary equipment for it (which I don't have)
- people at companies who test have a lot of fully dedicated time for it (which I don't have)
So it would be quite silly to pretend that I am doing something which I am not. What I can do is to repeat the tests done so far (for consistency). Perhaps I won't be able to set up a scene for testing ISOs above 6400 with exposures longer than 30" as I normally work with sufficient light (e.g. strobes or day light) and such low light scenario would be quite out of my range.
I will test the latest crop_rec_4k build and write again.
Checking the branches(code) is an easy way to follow what´s happening:
https://bitbucket.org/hudson/magic-lantern/branches/
The recent changes will always be on top. ML is heavily open source and changes to code are published all the time. Here is crop_rec_4k branch for instance:
https://bitbucket.org/hudson/magic-lantern/branch/crop_rec_4k
Learning how to compile and set up a source tree is a great way to start digging into code(I hardly can follow 1 percent of the stuff but it´s nice to read and compile it nevertheless :P):
Mac
http://www.magiclantern.fm/forum/index.php?topic=16012.0
Win
http://www.magiclantern.fm/forum/index.php?topic=15894.0
Equipment needed.
- Camera............check
- Grey matter between ears...........check
We are not a company, we are a bunch of guys continually doing stuff on our free time. a1ex tends to just have a bit more spare time then the rest of us (http://www.magiclantern.fm/forum/index.php?topic=7486.msg64150#msg64150).
The best part of this whole thing, is that we are not some company. We don't have a hill for shit to roll down when things go wrong, shareholders screaming and bitching and moaning, middle managers over stepping their pay grade, or all of the other negative things associated with a company. We understand that each person is helping, just because. Not for monetary gain, but for reasons that supersede money. So when we say, test as if doing QC for a company, we don't mean, do this and we will employ you as QC, we mean, spend a little extra effort with that grey matter between your ears then you might have otherwise have normally applied. Test outside of your range and don't just consume (http://www.magiclantern.fm/forum/index.php?topic=11879.msg115399#msg115399).
Cheers.
That last post sounds a little harsh. Feel free to tell me I'm being a prick via PM. I promise that's not my intention, but I would rather have you vent some steam, and continue to support the project further, then get discouraged and pack your bags.
Tested as promised:
CR2 (https://goo.gl/Nwfa3T)
160 0.8s
(https://snag.gy/wW1sXO.jpg) (https://snag.gy/Bk0Uom.jpg) (https://snag.gy/p5Pb9C.jpg)
160 1s
(https://snag.gy/JN5ptL.jpg) (https://snag.gy/MiFNQn.jpg) (https://snag.gy/fYaylb.jpg)
160 1.3s
(https://snag.gy/A9Upey.jpg) (https://snag.gy/UHY4vw.jpg) (https://snag.gy/psKq0N.jpg)
100 1.6s
(https://snag.gy/cY2Fmf.jpg) (https://snag.gy/UdTW1x.jpg) (https://snag.gy/HIuAFS.jpg)
100 2s
(https://snag.gy/d75Zte.jpg) (https://snag.gy/ZAu3vh.jpg) (https://snag.gy/6Rc5si.jpg)
100 2.5s
(https://snag.gy/d4iPWo.jpg) (https://snag.gy/tWxey7.jpg) (https://snag.gy/PfvHlL.jpg)
6400 30s 8.0
(https://snag.gy/sAS4j5.jpg) (https://snag.gy/yOb3Jn.jpg) (https://snag.gy/INtbcv.jpg) (https://snag.gy/wSbu5a.jpg)
6400 30s 7.1
(https://snag.gy/rvbkqH.jpg) (https://snag.gy/lzFy1v.jpg) (https://snag.gy/m1kX0L.jpg) (https://snag.gy/C6sXDQ.jpg)
6400 30s 9.0
(https://snag.gy/dVJGYl.jpg) (https://snag.gy/COJYSu.jpg) (https://snag.gy/WxdU3b.jpg) (https://snag.gy/3Laizo.jpg)
6400 30s 10.0
(https://snag.gy/zYJHb9.jpg) (https://snag.gy/0Nd8CW.jpg) (https://snag.gy/Iprum3.jpg) (https://snag.gy/Y31hvp.jpg)
Tested in the last 3 days in a real shoot (can't provide raw files, sorry):
- Some shots for which ML shows E0.1 are slightly clipped (when viewed in RawDigger afterwards)
- During shooting for some shots ML (QR) shows both not full ETTR and clipping, e.g. E0.3 and at the same time overexposure indication (dots in histogram). The strangest case was E0.9 with OE dots.
- Another case while shooting: I see E0.4 and I increase exposure time with 1/3EV (e.g. from 1/160 to 1/125). Then I take the same picture again (same light and composition, nothing changed) and I get overexposure indication. Expected: E0.1
I think we need to remember that WL calculation is being done on a tiny little ARM processor, and needs to be in real time.
Quote from: heyjoe on October 22, 2017, 05:39:51 PM
- Some shots for which ML shows E0.1 are slightly clipped (when viewed in RawDigger afterwards)
I think we need to accept here that E0.2 > E0.0 = clipped. Maybe only slightly, or maybe not at all.
Quote from: heyjoe on October 22, 2017, 05:39:51 PM
- During shooting for some shots ML (QR) shows both not full ETTR and clipping, e.g. E0.3 and at the same time overexposure indication (dots in histogram). The strangest case was E0.9 with OE dots.
Reproducible? I hope to have some time in the coming week to actually use my DSLR.
Quote from: heyjoe on October 22, 2017, 05:39:51 PM
- Another case while shooting: I see E0.4 and I increase exposure time with 1/3EV (e.g. from 1/160 to 1/125). Then I take the same picture again (same light and composition, nothing changed) and I get overexposure indication. Expected: E0.1
This one has been around since forever. Don't forget that electronic aperture is not always consistent.
Again, I think we need to allow E0.0>E0.2 tolerance. Either settle for very slightly underexposed, or bump shutter 1/3EV and settle for possible very slight overexposure.
Or find someone with coding talent and desire to increase accuracy. We're really splitting hairs though, since the current implementation is decades better then the JPG based histo that Canon provides.
For 1 and 3, when you have time to pixel peep the histogram, you have time to shoot two images 1/3EV apart, to cover all bases, and get that warm fuzzy feeling inside knowing that you shot ETTR as close as possible. It's what I do
Thanks for your time, the second bug needs further investigation.
BTW, I caught your last post before deletion. Thanks for your words.
Quote from: Audionut on October 28, 2017, 02:04:48 PM
I think we need to remember that WL calculation is being done on a tiny little ARM processor, and needs to be in real time.
Of course. But it is not real time in the sense that it happens at the time of exposure - it happens right after capture, right? Or are you saying that better accuracy would need some additional computation power which would make the displaying of clipping and histograms much slower?
Quote
I think we need to accept here that E0.2 > E0.0 = clipped. Maybe only slightly, or maybe not at all.
The problem is that it actually indicates underexposure (incomplete ETTR) for actually clipped image, i.e. one may think that everything is fine when there is actually a data loss (clipping) occurring.
Quote
Reproducible? I hope to have some time in the coming week to actually use my DSLR.
Should be. I have seen it at least 50 times.
Quote
This one has been around since forever. Don't forget that electronic aperture is not always consistent.
Again, I think we need to allow E0.0>E0.2 tolerance. Either settle for very slightly underexposed, or bump shutter 1/3EV and settle for possible very slight overexposure.
Or find someone with coding talent and desire to increase accuracy. We're really splitting hairs though, since the current implementation is decades better then the JPG based histo that Canon provides.
For 1 and 3, when you have time to pixel peep the histogram, you have time to shoot two images 1/3EV apart, to cover all bases, and get that warm fuzzy feeling inside knowing that you shot ETTR as close as possible. It's what I do
Thanks for your time, the second bug needs further investigation.
Considering all you say and what I asked earlier (about the possibility of having raw histograms in Play mode, not only in QR): What do you think about using libraw to the decode the CR2 file? RawDigger is based on libraw so I was just wondering if that could make the whole thing easier to code (and hopefully more accurate).
If it's reproducible, please upload some samples. The CR2 that caused the issue should be enough.
For decoding the CR2, I only need some really basic parsing (retrieving the StripOffsets tag from the CR2 header). Decoding the image data is going to be very slow on this CPU (several seconds, maybe even 1 minute), but I'll reuse Canon's decoder (very fast, running on JPCORE - probably some sort of DSP). The code should be small, without dependencies on large external libraries (but you can reuse code from them if the license allows you).
The accuracy issue comes from the clipping point not being known (it's variable). Canon code has a heuristic (http://www.magiclantern.fm/forum/index.php?topic=20579.msg190437#msg190437), but it's pretty conservative; their metadata can be 0.38 EV below the true clipping level (only from testing a few settings; if you brute-force the entire parameter space, you might find even more pathological cases). We have two cases:
- if the maximum value from your image is below Canon's heuristic, we can assume the image is not overexposed (I hope so)
- if it's above Canon's heuristic, it might be overexposed, or it might be not; we don't know for sure. In this case, I use the histogram heuristic to decide whether the image is clipped or not (whether there's a peak on the right side of the histogram). This is not 100% accurate, and I'm looking for counterexamples where my heuristic gives the wrong results.
That was the problem of deciding whether the image is overexposed or not.
The second problem - given an image that's not underexposed, how far you can push it to the right?
This one is harder because... if the image is not underexposed, you don't know the clipping point. We have Canon's heuristic, which is a lower bound (off by some 0.1 ... 0.4 stops, depending on exposure settings). So I just use that level as reference (unless the max value is already above that level).
Of course, you could take test images at any possible ISO x any possible shutter speed, write down the white level, check repeatability (different bodies of the same model might give different clipping points, they might change with temperature and so on), repeat for all other camera models supported by ML. Or you could imagine some sort of learning algorithm that uses the results from past autodetections (on overexposed images) to predict the clipping point on non-overexposed ones.
Note: the white level also varies with the aperture, but these variations are well understood (it's a digital gain that can be canceled). This simplifies the problem by "only" one order of magnitude.
The current approach doesn't learn anything - it attempts to figure out everything from the current image (from scratch).
Oh that's right, I forgot about the guessing game you have to play. When you have all of the data you speak of, raw_diag comes in handy when one knows that actual clipping values. :)
Quote from: a1ex on October 28, 2017, 03:58:28 PM
If it's reproducible, please upload some samples. The CR2 that caused the issue should be enough.
As I explained I cannot provide CR2 files because it was a commercial shoot and there are legal agreements involved. Sorry. But I am sure you can reproduce it if you try. Most of the time I was shooting at ISO 160 f8.0 and the main variable was exposure time (through which I controlled ETTR). Of course I made several exposures (+ and -) to make sure I have non-clipped files too.
Quote
The accuracy issue comes from the clipping point not being known (it's variable).
Yes, I thought about that and I remember you mentioned it.
Quote
Canon code has a heuristic (http://www.magiclantern.fm/forum/index.php?topic=20579.msg190437#msg190437), but it's pretty conservative; their metadata can be 0.38 EV below the true clipping level (only from testing a few settings; if you brute-force the entire parameter space, you might find even more pathological cases).
I have actually been thinking about making something like this - creating a map of the entire parameter space in order to find the maximum values for all possible combinations of ISO, speed, F-stop. But I am afraid that
1) I may burn my sensor through so many overexposure tests
2) I have no lens wider than 2.8
3) I am not sure if this is lens dependent, i.e. if for example 70-200/2.8 at 70mm will give the same saturation values as 24-70/2.8 at 70mm or if focal length plays a part in all that
4) it may take a long time which I don't have
5) it may turn out to be pointless
6) heuristic based on shape of the highlights may work better (what you currently do afaik)
Didn't you mention that you have found a register which contains the saturation value? Doesn't that help?
Quote
We have two cases:
- if the maximum value from your image is below Canon's heuristic, we can assume the image is not overexposed (I hope so)
- if it's above Canon's heuristic, it might be overexposed, or it might be not; we don't know for sure. In this case, I use the histogram heuristic to decide whether the image is clipped or not (whether there's a peak on the right side of the histogram). This is not 100% accurate, and I'm looking for counterexamples where my heuristic gives the wrong results.
Hm. What about if you loop programatically generated histograms through your algorithm and see if any particular shape gives wrong result? Would that help to improve the heuristic?
Quote
The second problem - given an image that's not underexposed, how far you can push it to the right?
This one is harder because... if the image is not underexposed, you don't know the clipping point. We have Canon's heuristic, which is a lower bound (off by some 0.1 ... 0.4 stops, depending on exposure settings). So I just use that level as reference (unless the max value is already above that level).
Of course, you could take test images at any possible ISO x any possible shutter speed, write down the white level, check repeatability (different bodies of the same model might give different clipping points, they might change with temperature and so on), repeat for all other camera models supported by ML. Or you could imagine some sort of learning algorithm that uses the results from past autodetections (on overexposed images) to predict the clipping point on non-overexposed ones.
Which adds 7), 8... etc. and the whole thing needs many man hours and many camera bodies to test completely. That's what I meant that testing as if for a company is not possible due to limited resources.
Quote
Note: the white level also varies with the aperture, but these variations are well understood (it's a digital gain that can be canceled). This simplifies the problem by "only" one order of magnitude.
Yes, you mentioned that. But if you start to account for that as a well known parameter - would that improve the situation?
Quote
The current approach doesn't learn anything - it attempts to figure out everything from the current image (from scratch).
I understand. Hm. How about a different approach:
Can you make (a menu option for) larger histogram e.g. full screen zoom of the highlight/shadow areas? Then one would be able to see better for oneself what is going on and hopefully manage to read the results of the heuristic using human intelligence instead of relying only on clip warnings and one number (which may not be so accurate as we see)? Currently the histogram is really microscopic and cannot be used for any significant evaluation but if it can - that may be helpful I think. This is similar to the UniWB method but considering that you can show the actual raw histograms, it will be far more accurate. To avoid obstructing the image too much it may draw just the contour of the histogram as an overlay (similar to RawTherapee. What do you think:
(https://snag.gy/4ajrED.jpg)
Another thing that comes to mind: is it possible to instruct the camera not to change the saturation value when exposure parameters change, i.e. to use a fixed maximum for any set of parameters and then things will be very simple?
Quote from: heyjoe on October 28, 2017, 06:50:05 PM
But I am afraid that............and the whole thing needs many man hours and many camera bodies to test completely. That's what I meant that testing as if for a company is not possible due to limited resources.
That's the entire point. No one wants to do all of that, not just you, for the reasons you have outlined, but because, it's splitting hairs. Who in their right mind would devote so much time an effort for 1/3EV. Oh, and then someone has to actually maintain that code (for the life of the project, until someone else gets the shits and removes it, or a better solution presents itself).
In an ideal world with unicorns and fairy's, it would be wonderful to also have an extremely accurate histogram. In the real world, we have to accept limitations. Just saying :D
Quote from: Audionut on October 28, 2017, 07:10:38 PM
That's the entire point. No one wants to do all of that, not just you, for the reasons you have outlined, but because, it's splitting hairs. Who in their right mind would devote so much time an effort for 1/3EV. Oh, and then someone has to actually maintain that code (for the life of the project, until someone else gets the shits and removes it, or a better solution presents itself).
In an ideal world with unicorns and fairy's, it would be wonderful to also have an extremely accurate histogram. In the real world, we have to accept limitations. Just saying :D
Yes, I understand what you are saying and that's why my first suggestion is based on the fact that the code which creates the histogram is already available. So all that may be needed is an option to draw it bigger. Then if the top 1EV of raw channel histograms can be zoomed so that one can see visually the clipping, we can rely on human intelligence, not only on heuristics (which may be limited in particular situations).
Pretty sure that has been discussed at some time, but I can't find the discussion with a quick search.
I like the idea. I think I would stick to that display most of the time, with ETTR hint in case the data falls outside of the display. Zebras for shadows.
Topic Split: Full-screen histogram WIP (http://www.magiclantern.fm/forum/index.php?topic=20882.0)
Thanks for explaining. Sounds good. Please let us know when there is a build to test.
BTW I wonder why the heuristic makes mistakes if it is based on that same info. Does it also use compressed CDF for calculations?
Quote from: a1ex on November 02, 2017, 09:11:39 PM
Median marker is 5 stops above the noise floor, shadow markers are at 2 stops above (more or less arbitrary choices).
This one had me scratching my head. Being stupid has it's advantages, one has so many moments of enlightenment. "Ah, there it is". I like the white level indicator on the EV scale also. Oh, and median markers for both the darkest and brightest channel.
My suggestions.
Move the DR and ETTR hints out of the data area to the top left. A cleaner solution would be to have transparent backgrounds while in the top left, but the overlay may get lost under a number of circumstances. Having said this, I don't have my camera here to check, but I can't recall a time where the overlays have been lost in the image. Otherwise they could be made smaller, but I have 20/20 vision.
I'd like to see the while level printed. If you decide to move the indicators mentioned above, I could see the value fitting there nicely. Otherwise, meh, I guess it would just be in a similar vain to yamlmo, and satisfying nitpickers.
Quote from: heyjoe on November 02, 2017, 11:57:58 PM
Could you please explain how we would use those while shooting?
http://www.magiclantern.fm/forum/index.php?topic=8539.msg80044#msg80044
Quote from: heyjoe on November 02, 2017, 11:57:58 PM
That offset is what I was asking for previously. Makes things much more readable. If you can add it globally left and right it would be great.
That offset on the right hand side is data, it's not arbitrary.
Quote from: heyjoe on November 02, 2017, 11:57:58 PM
Another thing: having channel histograms on top of each other makes it a little difficult to say which channels are clipped and which not. Sometimes one may want to clip one channel but not another.
Look very closely at how the color changes in the different examples where clipping has occurred.
http://www.magiclantern.fm/forum/index.php?topic=12096.0#post_Histogram
Quote from: Audionut on May 29, 2014, 05:41:00 PM
The colors in the histogram, represent the color channel in the camera (Red, Green, Blue).
You will also notice, that ML displays Cyan, Magenta and Yellow. If you look at the color chart below, you can see that Yellow falls in between Green and Red, and hence, Yellow represents data in both the Green and Red channels. Cyan being the data from Green and Blue channels, and Magenta being the data from Blue and Red channels. White indicates data from all color channels.
Consider this example.
(http://a1ex.magiclantern.fm/bleeding-edge/raw/hist/wip/cdf-log2-mark-redist-E5D3LL0001005.png)
Lets use the zoomed histogram top right for simplicity. You can see where the red channel is clipped (white), the blue channel is clipped (cyan) and the green channel is clipped (green).
Of course, white actually indicates that all of the channels have been clipped in that region, not just red. But it's the data above the white area that allows you to determine that the red channel clipping has finished with the end of the white marking, because above this white area is cyan (blue and green channels). And concurrently that blue channel clipping finishes with the cyan indication, because above this area is green (only the green channel is left).
Quote from: Audionut on November 03, 2017, 03:55:15 AM
http://www.magiclantern.fm/forum/index.php?topic=8539.msg80044#msg80044
My question was actually: how do we use 0.1% and 1% or any % values while shooting, considering that we have exposure controls, not %-controls.
Quote from: Audionut on November 03, 2017, 03:55:15 AM
That offset on the right hand side is data, it's not arbitrary.
Of course. I am just asking for offsetting the 16383 and the 0 from the screen edges. A thin dotted line can indicate the 16383 and the 0.
Quote
Look very closely at how the color changes in the different examples where clipping has occurred.
I know that. But while shooting (especially outdoors or in bright environment) pixel peeping to evaluate the color of a thin line on a small LCD is hardly the best usability. Evaluating shape is much more straightforward. Hence the suggestion (and the whole discussion about being able to evaluate histogram shape as a human, not just heuristically).
Don't you think my sketched suggestion would be much more readable and optimal for a small screen space? (Please bear in mind that if the image is underexposed the highlights histogram will be simply a flat line and the fact that the right edge of the CDF will be lower will not be a problem. And for the shadows vice versa. So it is an "automatic un-clutter".)
Quote from: heyjoe on November 03, 2017, 01:55:39 PM
My question was actually: how do we use 0.1% and 1% or any % values while shooting, considering that we have exposure controls, not %-controls.
If you have 500 pixels that are below 10%, and you want those 500 pixels to be above 10%, how do you move those 500 pixels?
Hint: You already have the controls necessary on your camera, and don't need a special % control.
My red for emphasis.
QuoteMidtone level:
- mathematically: median (which is a statistically robust indicator for overall exposure)
- interpretation: if it's too much on the left side (SNR too low), your image is likely too noisy
- how you should act: if it's too much on the left, and you still have clipped highlights, you should consider clipping more highlights or using HDR / dual ISO / change lighting / using a Nikon camera...
- note that you can find it pretty much anywhere in the highlighted range (not in the middle)
QuoteShadow level:
- mathematically: the value below which you have 5% of pixels (see http://en.wikipedia.org/wiki/Percentile )
- interpretation: underexposure warning on these boxes can be ignored (e.g. if you have clipped highlights and don't know of what to get rid first)
- what you should do: if you see both half-underexposure and overexpoure warnings, you should probably just move the exposure to the left and ignore the shadows; but if you see full underexposure and overexposure warnings, you should think whether you are OK with crushing some blacks / clipping some highlights / trying dual ISO / etc.
The next two posts in that thread then discuss further the midtone (median), and how that midtone can vary in it's exposure depending on the scene. Where talking the middle point of the exposed pixels. So 50% of the exposed pixels are below this marked exposure point, and 50% of the pixels are above the marked exposure point. So an underexposed scene will have the midtone marker move to the left, and an overexposed scene will have this midtone marker move to the right. Why?
Because in an underexposed scene, more pixels are towards to the left, an in an overexposed scene more pixels are towards the right. The midtone point (50%) moves with the exposure.
The other percentage points are exactly the same. Let's think about 10%. So this means that 10% of the pixels in the image are exposed below this point (the 10% marker on the CDF/Histogram). In an overexposed scene, or a low dynamic range scene that has been exposed to the right, this 10% marker is likely to fall well above the noise floor of the camera. All of the pixels have been exposed well.
In an underexposed scene, where you have not clipped the highlights, and the 10% marker is towards the left hand side (near the noise floor of the camera), then this is a clear indication that you should expose further to the right.
In a high dynamic range scene, where you have clipped highlights, and the 10% marker is towards the left hand side (near the noise floor of the camera), then you need to follow the advice in the quotes above. Either just crush that data to black (in post) negating the noise in those pixels, expose further to the right and clip more highlights, try dual ISO, or buy a Nikon/Sony instead for that scene. Only you can decide the best course of action, because you decide how to expose the scene based on the exposure feedback presented to you. There's some pretty nifty code in ML, but the AI isn't there yet, you still need to decide how best to expose the scene, ML can only guide you.
Quote from: heyjoe on November 03, 2017, 01:55:39 PM
Of course. I am just asking for offsetting the 16383 and the 0 from the screen edges. A thin dotted line can indicate the 16383 and the 0.
Well, 0 is a misnomer. The black level in Canon's is very close to 2048. This leaves headroom for proper evaluation of the noise sigma. The option in rawdigger is subtract black. This is on by default. Try turning it off if you want accurate data from the CR2.
In practice Canon's only hit 16383 on fast lenses, when in fast mode. So there's likely to always be an offset on the right hand side. And it looks to my eyes like there is already some offset on the left hand side. Why do you need some offset on the left hand side anyway. Is the idea to waste valuable space? At ISO 100 (best case scenario), the bottom three stops are useless anyway. Do you really need to know what's going on there, apart from, those pixels in that area are unusable. If you need to know how many pixels are in that area, use the % indicators.
Quote from: heyjoe on November 03, 2017, 01:55:39 PM
I know that. But while shooting (especially outdoors or in bright environment) pixel peeping to evaluate the color of a thin line on a small LCD is hardly the best usability. Evaluating shape is much more straightforward. Hence the suggestion (and the whole discussion about being able to evaluate histogram shape as a human, not just heuristically).
Pixel peeping on a small LCD is not the best usability, period. Maybe go see an eye doctor.
Quote from: heyjoe on November 03, 2017, 01:55:39 PM
Don't you think my sketched suggestion would be much more readable and optimal for a small screen space?
No, I don't. I would wonder why the red channel is brighter then the green channel. The Red channel is around 50% efficient as the green channel, and yet is at some arbitrary level above the green channel in your sketched suggestion. With the current implementation as shown by a1ex, I can immediately see where each color channel is relative to the others.
It's not an "automatic un-clutter", it's an automatic cluster fuck.
My personal favorite.
Quotehaving channel histograms on top of each other makes it a little difficult to say which channels are clipped and which not.......................Please bear in mind that if the image is underexposed the highlights histogram will be simply a flat line
If the image is underexposed, then we don't need to worry which color channels are clipped. Don't you think.
I should probably add some emoji's in there somewhere, but meh, you don't seem to place much effort in reading the links presented to you. Tit for tat. :D
Quote from: Audionut on November 03, 2017, 03:29:02 PM
If you have 500 pixels that are below 10%, and you want those 500 pixels to be above 10%, how do you move those 500 pixels?
While shooting I don't counts pixels or make calculations based on counts. Personally I watch that my light, composition, focus and ETTR. If I see visually (not numerically as a pixel count) an area which is important and must not be overexposed - I correct exposure, obviously.
Quote
Hint: You already have the controls necessary on your camera, and don't need a special % control.
My red for emphasis.
...
I have already read the post from the link. I definitely didn't read the next posts.
Thanks for the additional explanations. I am not sure if I will ever use that while shooting.
QuoteWell, 0 is a misnomer. The black level in Canon's is very close to 2048. This leaves headroom for proper evaluation of the noise sigma. The option in rawdigger is subtract black. This is on by default. Try turning it off if you want accurate data from the CR2.
It is interesting that you are critical about me not reading thoroughly another thread yet it seems you have not read my posts in the current one (e.g. #8) :) But I appreciate the explanations.
QuoteIn practice Canon's only hit 16383 on fast lenses, when in fast mode.
Which doesn't make it an impossible value.
QuoteWhy do you need some offset on the left hand side anyway. Is the idea to waste valuable space?
Because the edge of the screen is the border between 2 physically different materials. When you shoot outdoors there are all kinds of reflections and on the edges of plastic they can be even stronger and more obstructing. As someone who has optimized a lot of UI/UX I can say that it is not a good to place important info/graphics in an area with compromised visibility and rely on the viewer to stare harder.
QuoteAt ISO 100 (best case scenario), the bottom three stops are useless anyway.
How is that calculated?
Quote
Do you really need to know what's going on there, apart from, those pixels in that area are unusable.
No.
QuoteIf you need to know how many pixels are in that area, use the % indicators.
Maybe I will have to get used to that approach.
QuotePixel peeping on a small LCD is not the best usability, period. Maybe go see an eye doctor.
Or maybe kindly consider that one has suggested a UI optimization in order to avoid pixel peeping.
QuoteNo, I don't. I would wonder why the red channel is brighter then the green channel. The Red channel is around 50% efficient as the green channel, and yet is at some arbitrary level above the green channel in your sketched suggestion. With the current implementation as shown by a1ex, I can immediately see where each color channel is relative to the others.
Considering that the shape of channel histograms depends on the scene which is shot + the fact that all 4 channels show the same DR when testing, I wonder what you are talking about. I also wonder how this is related to the essence of the suggestion which is about placement and size of UI elements.
Quote
If the image is underexposed, then we don't need to worry which color channels are clipped. Don't you think.
You are mixing my posts and creating a new post from that with a totally different meaning which I never had in mind. So you are missing the point in what I said and trying to ridicule it based on misunderstanding.
The idea of having separate channel histogram is related to highlights clipping, not to underexposure. And my earlier post explains that having clipped only one or two channels may be ok in certain situations.
Quote
I should probably add some emoji's in there somewhere, but meh, you don't seem to place much effort in reading the links presented to you. Tit for tat. :D
I have read every link shared, even the ones which don't answer clearly a question which was asked.
Considering the jabs you like to make from time to time: If you consider my contribution to this thread worthless, disrespectful to the freedom of software or time wasting I am ready to shut up for good and still be thankful to the developers.
You display a consistent behavior of quoting tiny parts of other people's posts, to nitpick. You've been told once already to knock that shit off.
QuoteOr maybe kindly consider that one has suggested a UI optimization in order to avoid pixel peeping.
You're suggestions are kindly considered, always. The issue, is that you Sir take issue when your suggestions are not implemented, or there is any sort of 'attack' on those suggestions. Because your ego exceeds your ability by some margin.
QuoteAs someone who has optimized a lot of UI/UX I can say
There's nothing wrong with a big ego, when applied correctly the benefits are great. But you seem to want to waltz into this community and expect a level of respect.
I think the sad part is, that you've been given a level of respect, but that level doesn't fit within the expectations of your ego, so you want to start throwing toys around.
I strongly suggest that you take a few days off, if for no other reason then to show you can have patience. Perhaps a1ex is already working on your solution, or at least, has decided to try and implement the idea, as time allows. Remember, ML isn't some multi-national company with thousands of employees, it's coded in the garage with spare time, buy a couple of people.
Audionut, I was trying to collaborate by sharing things from experience with someone who was interested in turning that into ML functionality and it was going quite well for some time. Then you came in the thread with a series of unrealistic demands, innuendos and all the micro trolling which I was trying not to respond to.
I understand that it is difficult for you to accept that you may actually be talking to someone who can share useful suggestions and you would rather abuse him (with a "level of respect"), call his clarifications "that shit" or "big ego" etc. However that is contrary to the idea of communing and the aggression in your latest reply has gone too far.
Thank you a1ex. Great work. Forgive me if I have said anything inappropriate.
Quote from: heyjoe on November 04, 2017, 02:41:08 AM
the micro trolling which I was trying not to respond to.
Well, at least you tried.........right.
I think society is getting weaker by the day. "I tried" is an excuse I hear a lot of these days.
A firefighter who runs through a burning building, risking life and limb, but unable to reach the person trapped at the rear of the building, that's trying, that's worth consoling. A keyboard warrior who tries not to press buttons on a keyboard, but fails.........
While you're taking a break, learn to follow the advise of a moderator (http://www.magiclantern.fm/forum/index.php?topic=20579.msg191468#msg191468), and read this (http://www.catb.org/esr/faqs/smart-questions.html#not_losing).