It looks like the tag that ACR is reading for tint is "AsShotNeutral". (After you change something in ACR, it writes a "tint" tag, but this is apparently the value ACR uses to generate that tag.)
exiftool *.dng -asshotneutral
exiftool img_0000.dng -asshotneutral="0.473635 1.05 0.624"
In all the Dual ISO .dngs I looked at so far, the values are always 0.473635, 1, 0.624. As far as correcting the tint, I haven't tried many files yet but I did try a few different numbers for the middle value, which changed the tint in ACR as follows:
1.100 = +27
1.050 = +10
1.010 = -4
1.000 = -8
0.999 = -8
0.990 = -11
0.900 = -46
Then I tried a CeroNoice/dng_validate .tif file. These show up completely green in ACR. To get a ceronoise .tif that isn't green in ACR, do the following (probably will have to change the values for AsShotNeutral):
ceronoice img_0001.cr2 img_0002.cr2 img_0003.cr2
dng_validate.exe -3 out out.dng
exiftool out.tif -asshotneutral="0.473635 1 0.624"
Nice find. Did you try only raw files from 5D2 or also from other cameras?
Quote from: engardeknave on January 31, 2014, 11:00:49 AM
It looks like the tag that ACR is reading for tint is "AsShotNeutral". (After you change something in ACR, it writes a "tint" tag, but this is apparently the value ACR uses to generate that tag.)
Strange, as acr defaults to "adobe standard" for camera calibrarion - well, but as long as it works :-p
It's great you're working on this, dual_iso is great but the tint problem is annoying and needs a lot of time of manual fine-tuning to get an acceptable result, and even then it's just guesswork.
The question is: how do you tell acr what tint (and wb) is correct? Currently when importing a dual_iso dng in LR, the "as shot" option defaults to a fixed nonsense value, and I'm not sure what the "auto" option does even if seems to produce ok-ish results.
QuoteDid you try only raw files from 5D2 or also from other cameras?
I'm working on .dngs produced by cr2hdr from the 5D2.
QuoteStrange, as acr defaults to "adobe standard" for camera calibrarion
Actually, it looks like mine is defaulting to "As Shot".
QuoteThe question is: how do you tell acr what tint (and wb) is correct?
I have no idea if it's always off by the same amount or not. As I convert more files, I'll learn more. I don't place much confidence in what the camera thinks is the correct value though, even shooting normally.
Quote from: engardeknave on January 31, 2014, 11:00:57 PM
Actually, it looks like mine is defaulting to "As Shot".
I was talking about the camera calibration (at the very bottom of lr dev module) as this is where the "AsShotNeutral" tag belongs - or is this really for the wb (at the very top)... there's no "neutral" option in there? My wb also defaults to "as shot".
Oh, I just misread that. I don't use Lightroom.
Did some investigating and the camera profiles "Adobe Standard", "Camera Standard", and "Camera Neutral" all had the same white balance and tint values, with "Embedded" being slightly different. Then I did a exiftool -asshotneutral="0.473635 1.05 0.624". For all those camera profiles, the white balance presets "As Shot" and "Auto" changed while all other remained exactly the same. So ACR appears to calculate the values of "As Shot" and "Auto" using AsShotNeutral regardless of camera profile.
Adobe Standard/Camera Standard/Camera Neutral
As Shot 4800 -8
Auto 5850 +5
Daylight 5500 +10
Cloudy 6500 +10
Shade 7500 +10
Tungsten 2850 0
Flouresc 3800 +21
Flash 5500 0
Custom 5001 +10
Embedded
As Shot 4750 -9
Auto 5800 +4
Other values unchanged
After -asshotneutral="0.473635 1.05 0.624"
Adobe Standard/Camera Standard/Camera Neutral
As Shot 5000 +10
Auto 5850 +5
Other values unchanged
Embedded
As Shot 4950 +9
Auto 5800 +4
Other values unchanged
God damn it, I just realized now that I'm getting 4800/-8 for every single Dual ISO.
Quote from: engardeknave on February 01, 2014, 06:06:01 AM
God damn it, I just realized now that I'm getting 4800/-8 for every single Dual ISO.
Oh my, we're making real progress here, I'm always getting 5600/+20 for "AsShot" with the 6d :-p ... "Auto" differs and usually looks ok-ish as I wrote above, but I didn't do any test shots yet to see how dual_iso acr-autowb matches non-dual_iso Canon-autowb or a calibration with x-rite passport. So much still to be done here, doh.
I just tried a bunch of tags in some .cr2 files and it seems like none of the obvious suspects except for one has any effect in ACR. That tag would be WB_RGGBLevelsAsShot. This one does vary in each file, and it is indeed copied to the .dng output of cr2hdr. But it doesn't seem to have an effect on .dng files in ACR. AsShotNeutral does not exist in the .cr2. So it would seem we have to translate WB_RGGBLevelsAsShot values into AsShotNeutral values.
In my cr2s the values for WB_RGGBLevelsAsShot are something like: 2564 1168 1168 2445, with the two middle values never varying (over the 8 or so files I looked at). In my dngs, I always get the same values for AsShotNeutral: 0.4736350037 1 0.624.
Quote from: engardeknave on February 02, 2014, 12:24:25 PM
I just tried a bunch of tags in some .cr2 files and it seems like none of the obvious suspects except for one has any effect in ACR. That tag would be WB_RGGBLevelsAsShot. This one does vary in each file, and it is indeed copied to the .dng output of cr2hdr. But it doesn't seem to have an effect on .dng files in ACR. AsShotNeutral does not exist in the .cr2. So it would seem we have to translate WB_RGGBLevelsAsShot values into AsShotNeutral values.
Yes, that does sound reasonable - I also suspect acr somehow computes the "as shot" wb itsself as I also couldn't find any cr2 tag that does the trick. I then gave up, great you're more persistent!
Quote from: engardeknave on February 02, 2014, 12:24:25 PM
In my cr2s the values for WB_RGGBLevelsAsShot are something like: 2564 1168 1168 2445, with the two middle values never varying (over the 8 or so files I looked at). In my dngs, I always get the same values for AsShotNeutral: 0.4736350037 1 0.624.
The obvious questions are:
* What's the algorithm to get a correct AsShotNeutral from WB_RGGBLevelsAsShot (*if* that's the only basis of the computation)?
* Obviously, acr for some reason fails to do this with dual_iso shots and we're getting a fixed/wrong AsShotNeutral, but it's working on non_dual iso shots - why's that?
I admit I'm completely clueless on how to go on from here, I'm certainly not geek enough to figure out how acr computes the value and apply this knowledge to cr2hdr ... which is unfortunate, since the wb/tint problem is serious enough to consider the dual_iso->acr workflow as buggy. One possibility would be to ask a question in some Adobe forum where the acr devs hang out.
Edit: One possible test would be to run acr not on the interlaced dual_iso cr2, but on a half-res dng or modified cr2 with only one iso - maybe then acr would compute the correct AsShotNeutral, and we could simply copy this tag in the real cr2->dng workflow?
QuoteI also suspect acr somehow computes the "as shot" wb itsself
WB_RGGBLevelsAsShot did affect both "auto" and "as shot".
QuoteObviously, acr for some reason fails to do this with dual_iso shots and we're getting a fixed/wrong AsShotNeutral, but it's working on non_dual iso shots - why's that?
It probably just treats dngs differently.
QuoteI admit I'm completely clueless on how to go on from here, I'm certainly not geek enough to figure out how acr computes the value and apply this knowledge to cr2hdr
We change the values of AsShotNeutral in a .dng and watch how it affects temperature and tint in ACR. We do the same thing with WB_RGGBLevelsAsShot in a .cr2. It needs something like +18 tint, which will be easy to figure out without even fundamentally understanding how it works. For now I've been doing +.05 on the middle value of AsShotNeutral. See "After -asshotneutral" in #5 above.
QuoteOne possible test would be to run acr not on the interlaced dual_iso cr2, but on a half-res dng or modified cr2 with only one iso - maybe then acr would compute the correct AsShotNeutral, and we could simply copy this tag in the real cr2->dng workflow?
The value is already there in the .cr2, and it does get copied to the .dng. Adobe just doesn't use it when it opens a .dng file.
Quote from: engardeknave on February 02, 2014, 07:40:12 PM0
We change the values of AsShotNeutral in a .dng and watch how it affects temperature and tint in ACR. We do the same thing with WB_RGGBLevelsAsShot in a .cr2. It needs something like +18 tint, which will be easy to figure out without even fundamentally understanding how it works. For now I've been doing +.05 on the middle value of AsShotNeutral. See "After -asshotneutral" in #5 above.
Thanks again for taking this trial & error procedure upon you, I currently don't have the time like in the olden days for something like this :-o
My investigation dead-ended when I googled "RGGB" and found a thread on this weird, obscure forum (http://www.magiclantern.fm/forum/index.php?topic=6779.0). The problem has either been solved already, or smart people who know math need to take a look at it.
Quote from: engardeknave on February 06, 2014, 09:24:49 PM
My investigation dead-ended when I googled "RGGB" and found a thread on this weird, obscure forum (http://www.magiclantern.fm/forum/index.php?topic=6779.0). The problem has either been solved already, or smart people who know math need to take a look at it.
Sorry to hear this, but it isn't unexpected - as I don't understand one word of the linked thread, I'd throw my other suggestion in the ring again: Run only one part of the dual_iso cr2 through acr & copy the resulting wb/tint (which is hopefully correct) to the actual full cr2hdr output...
I'm currently using exiftool to bump AsShotNeutral up by a static amount, just so that's it's not a catastrophe if I forget to adjust it. This is fine for my purposes.
Quote from: engardeknave on February 02, 2014, 12:24:25 PM
In my cr2s the values for WB_RGGBLevelsAsShot are something like: 2564 1168 1168 2445, with the two middle values never varying (over the 8 or so files I looked at). In my dngs, I always get the same values for AsShotNeutral: 0.4736350037 1 0.624.
Those AsShotNeutral values are the default values in
chdk-dng.c, so that's why DNGs all have that fixed white balance (with the conversion to temperatures and tint varying with camera and calibration). With DNGs, ACR seems to only look at the AsShotNeutral values, so it always sees a fixed white balance for dual_iso DNGs, even if WB_RGGBLevelsAsShot is saying something different.
Quote from: Marsu42 on February 02, 2014, 03:32:30 PM
* What's the algorithm to get a correct AsShotNeutral from WB_RGGBLevelsAsShot (*if* that's the only basis of the computation)?
According to the thread linked above (http://www.magiclantern.fm/forum/index.php?topic=6779.0), the proper conversion looks to be straightforward. The four values for WB_RGGBLevelsAsShot {R, G, G, B} convert to the three values for AsShotNeutral as {G/R, G/G, G/B}. For example, {2564 1168 1168 2445} converts to {0.4555 1 0.4777}. I don't know exactly how to handle the two G values if they are different, but if they are more than 1 unit different, something is probably wrong with your camera sensor.
As of November,
chdk-dng.c has the function
dng_set_wbgain for specifying values different from the default AsShotNeutral values be written to DNGs, so the above conversion should be "easy" to implement.
Alright, so the algorithm for fixing it should be as easy as reading WB_RGGBLevelsAsShot with exiftool and plugging these numbers in dng_set_wbgain?
(I still don't understand what exactly is WB_RGGBLevelsAsShot: is it the WB setting at the moment of taking the picture, as you have set in Canon menu?)
I took a regular photo followed by a dual ISO (100/800) photo of the same scene.
Regular CR2, with the camera set to "Tungsten"The "WB RGGB Levels" values and the "WB RGGB Levels As Shot" values are the same. Curiously, the "As Shot" values are slightly different from the apparently hard-coded "Tungsten" values. If I set the camera to "Auto", the "As Shot" values match the "Auto values".
WB RGGB Levels As Shot : 1656 1082 1082 2121
Color Temp As Shot : 3210
WB RGGB Levels Auto : 2012 1117 1117 2155
Color Temp Auto : 3604
WB RGGB Levels Measured : 1379 1115 1117 3185
Color Temp Measured : 2400
WB RGGB Levels Daylight : 2127 1024 1024 1434
Color Temp Daylight : 5200
WB RGGB Levels Shade : 2422 1024 1024 1228
Color Temp Shade : 7000
WB RGGB Levels Cloudy : 2275 1024 1024 1317
Color Temp Cloudy : 6000
WB RGGB Levels Tungsten : 1657 1083 1083 2125
Color Temp Tungsten : 3200
WB RGGB Levels Fluorescent : 1938 1040 1040 1931
Color Temp Fluorescent : 3793
WB RGGB Levels Kelvin : 2378 1024 1024 1254
Color Temp Kelvin : 6730
WB RGGB Levels Flash : 2310 1024 1024 1301
Color Temp Flash : 6250
Raw Measured RGGB : 57436 67183 73377 26751
...
WB RGGB Levels : 1656 1082 1082 2121
The "As Shot Neutral" values that are added appear to follow the suggested conversion: 1082/1656 = 0.653382 and 1082/2121 = 0.510137.
As Shot Neutral : 0.653382 1 0.510137
Note that the "Auto" values are clearly being thrown off by the ISO switching! The "As Shot" values match these bad "Auto" values when the camera is set to "Auto" white balance.
WB RGGB Levels As Shot : 1656 1082 1082 2121
Color Temp As Shot : 3210
WB RGGB Levels Auto : 2970 1024 1024 1369
Color Temp Auto : 7448
WB RGGB Levels Measured : 5212 4258 582 1465
Color Temp Measured : 10675
WB RGGB Levels Daylight : 2127 1024 1024 1434
Color Temp Daylight : 5200
WB RGGB Levels Shade : 2422 1024 1024 1228
Color Temp Shade : 7000
WB RGGB Levels Cloudy : 2275 1024 1024 1317
Color Temp Cloudy : 6000
WB RGGB Levels Tungsten : 1657 1083 1083 2125
Color Temp Tungsten : 3200
WB RGGB Levels Fluorescent : 1938 1040 1040 1931
Color Temp Fluorescent : 3793
WB RGGB Levels Kelvin : 2378 1024 1024 1254
Color Temp Kelvin : 6730
WB RGGB Levels Flash : 2310 1024 1024 1301
Color Temp Flash : 6250
Raw Measured RGGB : 79883 98825 796744 289355
...
WB RGGB Levels : 1656 1082 1082 2121
The "As Shot Neutral" values in the dual ISO DNG are just the defaults ("0.473635 1 0.624"), and the white balance is way off. If I patch it with "0.653382 1 0.510137", the white balance becomes as expected.
Quote from: a1ex on March 18, 2014, 09:51:15 PM
Alright, so the algorithm for fixing it should be as easy as reading WB_RGGBLevelsAsShot with exiftool and plugging these numbers in dng_set_wbgain?
So, it looks like this algorithm will work as long as the white balance is not set to "Auto" on the camera. The "Auto" values are being affected by the ISO switching, and I don't know how to fix it.
The "As Shot" and "WB RGGB Levels" are the same in both.
Wouldn't it make sense to make the WB from them?
If you set the camera to "Auto" white balance, you get:
WB RGGB Levels As Shot : 2970 1024 1024 1369
Color Temp As Shot : 7448
WB RGGB Levels Auto : 2970 1024 1024 1369
Color Temp Auto : 7448
...
WB RGGB Levels : 2970 1024 1024 1369
They should be close to "2012 1117 1117 2155". In other words, the "As Shot" values are bad because the "Auto" values are bad. There's probably some way to correct the values, possibly by using the difference between the ISOs and/or using the "Measured" values (I have no clue what those are).
It sounds like when WB is set to auto, cr2hdr should compute WB on its own somehow (after conversion).
Some tests which may give useful clues:
Quote from: a1ex on March 18, 2014, 06:36:39 PM
Did you check if converting CR2's to Adobe DNG before running cr2hdr helps? Did you try to copy the exif info from an Adobe DNG file to cr2hdr output?
Quote from: a1ex on March 19, 2014, 09:39:35 AM
It sounds like when WB is set to auto, cr2hdr should compute WB on its own somehow (after conversion).
Waste of time IMO. There are a million programs that can calculate WB.
You can create an import preset in LR, that allows you to automatically import images, with LR's own automagic WB, for instance. Or sunny, cloudy, user defined WB, etc, etc.
Quote from: a1ex on March 19, 2014, 09:39:35 AM
Some tests which may give useful clues:
I'll test this later tonight.
Quote from: Audionut on March 19, 2014, 10:49:46 AM
Waste of time IMO. There are a million programs that can calculate WB.
You can create an import preset in LR, that allows you to automatically import images, with LR's own automagic WB, for instance. Or sunny, cloudy, user defined WB, etc, etc.
A preset doesn't really help much if I import a large number of photos that are a mixture of dual and non-dual ISO images, some of which were taken with auto WB and some of which were not (that's a common situation for me). It would certainly be more convenient if the auto WB value was correct in at least the DNG output by cr2hdr, if not the dual ISO CR2 itself. Or am I missing a trick here?
If the correct AsShot values could be interpreted, and plugged into the dual_iso output, that would be one thing.
But to develop code that attempts a WB setting from the image data, this is the same thing that PP tools do.
Also note, there is no correct auto WB. Either in camera, or otherwise. It's a best guess based on the image data.
There's another benefit of this WB correction: when using the new --soft-film setting, you will already have a good guess for WB (either from exif or from some sort of auto), which may be close enough to make the --wb setting fully optional.
Right now, if you want to use --soft-film and --wb, you need 2 passes of cr2hdr: first pass to get a good approximation of WB (can be with --fast, but still, it's an extra step), then adjust WB in ufraw and read the multipliers, then run a second pass for the final render.
What'd I'd like is for alternating frames of regular shots and dual ISO shots to have the same white balance, even if the in-camera white balance is inaccurate. When using tools like the Lightroom plugin (http://www.magiclantern.fm/forum/index.php?topic=11056.0), using dual ISO then becomes very low "friction" for the casual user.
Quote from: a1ex on March 18, 2014, 06:36:39 PM
Did you check if converting CR2's to Adobe DNG before running cr2hdr helps? Did you try to copy the exif info from an Adobe DNG file to cr2hdr output?
If I convert the dual ISO CR2 directly to a DNG using ACR, it's clear that Adobe just divides the "WB RGGB Levels As Shot" values (i.e., the algorithm suggested above). The correct "As Shot Neutral" values should be close to "0.653382 1 0.510137". Thus, Adobe is not being "smart" in any way, and we need to fix the "As Shot" values.
As Shot Neutral : 0.344781 1 0.747991
...
WB RGGB Levels As Shot : 2970 1024 1024 1369
Color Temp As Shot : 7448
WB RGGB Levels Auto : 2970 1024 1024 1369
Color Temp Auto : 7448
WB RGGB Levels Measured : 5160 4224 582 1457
Color Temp Measured : 10719
As additional information, the "Auto" white balance information for regular shots taken at ISO 100 and ISO 800 is nearly the same (and correct), so the bad "Auto" values in the dual ISO shot is not just a straightforward mixing of the two.
Ah, slight correction. Adobe may not be looking at the "WB RGGB Levels As Shot" values directly. The CR2 has tags "Red Balance" and "Blue Balance", clearly calculated from the "WB...As Shot" values, that can be inverted to obtain the "As Shot Neutral" values. That is, if we figure out how to fix the "WB...As Shot" values, we also need to recalculate these "*Balance" values to make sure that the white balance information is consistent in the CR2.
From a diff, here's the list of tags that may be useful for the fix, if there's any hope of not looking at the image data itself.
Regular CR2 (ISO 100)
Measured RGGB : 858 1024 1024 389
WB RGGB Levels As Shot : 2009 1117 1117 2147
Color Temp As Shot : 3611
WB RGGB Levels Auto : 2009 1117 1117 2147
Color Temp Auto : 3611
WB RGGB Levels Measured : 1376 1115 1117 3177
Color Temp Measured : 2400
Raw Measured RGGB : 151580 192577 185025 69494
WB RGGB Levels : 2009 1117 1117 2147
Blue Balance : 1.922113
Red Balance : 1.798568
Dual ISO CR2 (ISO 100/800)
Measured RGGB : 185 1024 1024 675
WB RGGB Levels As Shot : 2970 1024 1024 1369
Color Temp As Shot : 7448
WB RGGB Levels Auto : 2970 1024 1024 1369
Color Temp Auto : 7448
WB RGGB Levels Measured : 5160 4224 582 1457
Color Temp Measured : 10719
Raw Measured RGGB : 99230 126060 976974 359041
WB RGGB Levels : 2970 1024 1024 1369
Blue Balance : 1.336914
Red Balance : 2.900391
I should point out the hard-coded white balance on dual ISO shots is not a green tint on the 50D, but rather the shots are awash in magenta. In ACR, the temperature is 4850, and the tint is +46. Even if we don't make any headway on reconstructing or recalculating a proper white balance, the hard-coded defaults in cr2hdr ought to be model-specific.
Edit: corrected the temperature/tint numbers
Quote from: a1ex on March 19, 2014, 12:33:34 PM
There's another benefit of this WB correction: when using the new --soft-film setting, you will already have a good guess for WB (either from exif or from some sort of auto), which may be close enough to make the --wb setting fully optional.
Good point.
Do you think there are digic registers involved? If so, can you lead me down a path that doesn't involve hand checking each register.
I'm not sure how Canon's Auto WB algorithm works, but... can you check if it depends on the picture style sharpness setting?
(just to confirm a wild guess)
Nope. It doesn't.
Alright, so it's likely to be computed from raw data directly. (Audionut, you did the test with a dual ISO file, right?)
I don't know what exactly it's doing, but if it's doing an average or median of some pixels, and we know which these pixels are, it might be possible to find out in which direction it biases and undo that bias.
It may be as simple as their algorithm (WBINTEG strings in Canon firmware) is averaging different ratios of dark/bright pixels for the 3 color channels; if that's true, all we need to know to perform the correction would be these ratios.
So, it may be helpful if somebody could take pairs of images, like ayshih did, of the same scene at regular ISO vs dual ISO (for example, ISO 400 vs 100/1600, or whatever you think it's useful). Try a few more scenes in different lighting (to cover a large part of the white balance range). Then write down a table like this:
RGGB regular RGGB dual ISO (as shot, for both columns)
1,2,2,3 4,5,5,6
7,8,8,9 10,11,11,12
...
Once we have such a table, we can try to look for patterns.
I tested both Canon and dual_iso.
I tested just sharpness settings 1 and 7 previously. Can someone confirm with other sharpness values?
I'm seeing the same AsShot numbers for dual_iso (with Canon Auto WB), regardless of the (color) temperature of the scene.
Sharpness: 1 and 7 are enough, no more tests needed.
As Shot test (5D3, Auto WB):
WB RGGB Levels As Shot : 1935 1024 1024 1664
Color Temp As Shot : 4902
WB RGGB Levels As Shot : 1678 1024 1024 2897
Color Temp As Shot : 3200
WB RGGB Levels As Shot : 1473 1024 1024 2405
Color Temp As Shot : 3200
WB RGGB Levels As Shot : 1446 1024 1024 2351
Color Temp As Shot : 3200
WB RGGB Levels As Shot : 2217 1024 1024 1978
Color Temp As Shot : 4710
WB RGGB Levels As Shot : 1691 1024 1024 2842
Color Temp As Shot : 3242
Shots 1,3,5: ISO 400.
Shots 2,4,6: ISO 100/1600.
1,2: outside, 3,4: tungsten light, 5,6: computer monitor.
These were handheld, so don't rely on their accuracy.
Some exploratory math using my dual ISO (100/800) shot!
Raw Measured RGGB
99230 126060 976974 359041
My guess is that these are straight sums of a subset of the pixels in the raw data. In fact, given how the second G value is nearly 8 times the first G value (the ISO ratio!), it looks like the sum is not mixing the two ISOs together (this may be different on cameras other than the 50D). Thus, the first two values (RG) are for ISO 100, and the second two values (GB) are for ISO 800.
Measured RGGB
Now to see if I can reproduce the values reported in "Measured RGGB" ("185 1024 1024 675"). Averaging the two G values in "Raw Measured RGGB",
99230 551517 551517 359041
and then renormalizing so the two G values are 1024
184 1024 1024 667
It's very close!
WB RGGB Levels Measured
Of course, the above isn't particularly useful for our objective here. Can we reproduce "WB RGGB Levels Measured" ("5160 4224 582 1457")? If I divide the "Raw Measured RGGB" into 5.3e8 (a magic number), the result is
5341 4204 543 1476
The match is good, but not great. There may be some hidden, channel-dependent corrections that need to be applied, which would complicate any approach that starts with the raw data.
WB RGGB Levels Measured (corrected)
What can we do if we start with just "WB RGGB Levels Measured" ("5160 4224 582 1457")? We can renormalize R and B values such that their respective G values are 1116 (you'll see why)
1363 1116 1116 2794
This should be compared against the "WB RGGB Levels Measured" values from the regular shot ("1376 1115 1117 3177"). It's rather close, with the discrepancy in the GB value pair almost certainly due to the fact that the dual ISO shot has saturation (the GB pair is for ISO 800, remember).
WB RGGB Levels Auto
I have no guesses on how to reproduce "WB RGGB Levels Auto" ("2970 1024 1024 1369"). The same procedure would probably take the corrected "WB RGGB Levels Measured" to the corrected "WB RGGB Levels Auto" (i.e., something close to "2009 1117 1117 2147"). From Google searching, it looks like, on some cameras, the values for "WB RGGB Levels Measured" and "WB RGGB Levels Auto" can be the same, but that is definitely not the case on the 50D. There looks to be an additional transformation needed. Can you guys compare these tags for your shots?
In autoWB mode, I'm seeing the same values in,
WB RGGB Levels AsShot
WB RGGB Levels Auto
WB RGGB Levels Measured
5D3.
Quote from: Audionut on March 19, 2014, 04:55:12 PM
I'm seeing the same AsShot numbers for dual_iso (with Canon Auto WB), regardless of the (color) temperature of the scene.
Yup, that's the problem, what really hurts is that the tint value (magenta/cyan) isn't measured as the organge/blue wb is much more subjective and doesn't matter that much.
I'm pretty sure that all color settings are derived from the RGB values. And it's the funky RGB values that are throwing off the G/M calculations.
Quote from: Audionut on March 20, 2014, 06:55:21 AM
In autoWB mode, I'm seeing the same values in,
WB RGGB Levels AsShot
WB RGGB Levels Auto
WB RGGB Levels Measured
5D3.
Hmm, even on dual ISO shots? Can you post the tags like the following from one of your dual ISO shots?
50D Dual ISO CR2 (ISO 100/800)
Measured RGGB : 185 1024 1024 675
WB RGGB Levels As Shot : 2970 1024 1024 1369
Color Temp As Shot : 7448
WB RGGB Levels Auto : 2970 1024 1024 1369
Color Temp Auto : 7448
WB RGGB Levels Measured : 5160 4224 582 1457
Color Temp Measured : 10719
Raw Measured RGGB : 99230 126060 976974 359041
WB RGGB Levels : 2970 1024 1024 1369
Blue Balance : 1.336914
Red Balance : 2.900391
Is the ISO pattern on the 5D3 GBRG or RGGB? The 50D is GBRG.
Yes, both types.
Here, dual_iso
MeasuredRGGB : 505 1024 1024 523
ColorDataVersion : 10 (1DX/5DmkIII/6D/70D/100D/650D/700D/M)
WB_RGGBLevelsAsShot : 1893 1024 1024 2260
ColorTempAsShot : 4044
WB_RGGBLevelsAuto : 1893 1024 1024 2260
ColorTempAuto : 4044
WB_RGGBLevelsMeasured : 1893 1024 1024 2260
ColorTempMeasured : 4044
RawMeasuredRGGB : 36328 68077 67802 34351
No WB RGGB Levels, or Blue/Red Balance. But there is these
WhiteBalanceRed : 0
WhiteBalanceBlue : 0
After a bunch of investigation, here is my current state of understanding (long post!).
How Canon determines white balance(1) Choose a subset of the sensor pixels. More on this later.
(2) Add up the (black-level-subtracted) ADC values from this pixel set. These values are recorded as "Raw Measured RGGB", e.g.:
Raw Measured RGGB : 99230 126060 976974 359041
In this 50D dual ISO shot, the RG pair appears to only sample the primary ISO (100) while the GB pair appears to only sample the recovery ISO (800), which strongly indicates that there is line skipping going on in step (1). If the ADC values are not being scaled down in this sum, then it could mean that the white balance is being computed from as few as ~100 pixels.
(3) Divide the previous values into large number that is proportional to the number of pixels in that channel (essentially, this is the inverse of the average ADC value). These values are recorded as "WB RGGB Levels Measured", e.g.:
WB RGGB Levels Measured : 5160 4224 582 1457
Because the dividend appears to be channel-dependent, I suspect that Canon masks out a subset of the pixels in each channel (possibly those that fall below a certain threshold) to keep them from biasing the white balance.
(4) Transform the "WB RGGB Levels Measured" values into a temperature ("Color Temp Measured") and a tint (not recorded in the CR2).
Color Temp Measured : 10719
(5) If the temperature is outside of some "acceptable" range, choose a better temperature through some algorithm. This value is recorded as "Color Temp Auto", e.g.:
Color Temp Auto : 7448
That is, Canon decided that 10719 K was way too hot, and set a new temperature of 7448 K. As an alternate example, from a regular shot in tungsten lighting:
Color Temp Measured : 2400
Color Temp Auto : 3611
Canon decided that the "Measured" temperature was too cold, and increased the temperature. I suspect this is why I typically can't rely on AWB for tungsten lighting.
(6) Using the (corrected) temperature and the previously determined tint, which has
not been changed, invert the transforms in step (5). These values are stored in "WB RGGB Levels Auto", e.g.:
WB RGGB Levels Auto : 2970 1024 1024 1369
Even when the temperature is not changed, the "WB...Measured" and "WB...Auto" values can be slightly different, which suggests that this transform-inverse-transform step always takes place.
(7) Assuming the camera is set to AWB, copy these values to "WB RGGB Levels As Shot"
WB RGGB Levels As Shot : 2970 1024 1024 1369
Color Temp As Shot : 7448
and, on the 50D at least, compute "Red Balance" and "Blue Balance"
WB RGGB Levels : 2970 1024 1024 1369
Blue Balance : 1.336914
Red Balance : 2.900391
The convenient approach is to use the EXIF information to construct a better white balance.
- For cameras like the 5D3, we may be fortunate that the RGGB values are always determined from one ISO (as opposed to mixing them together), and so you'll just have to set ISOs accordingly. For example, 100/800 might have correct white balance, while 800/100 does not. If the ISOs are mixed, then all balances will be thrown off by saturation, with no obvious way to correct them.
- For cameras like the 50D, it looks to be "easy", because you can just renormalize "WB RGGB Levels Measured" (see my earlier post (http://www.magiclantern.fm/forum/index.php?topic=10265.msg107526#msg107526)). One color balance (i.e., red or blue) will be correct, and the other one may be somewhat off due to saturation. Note that using these corrected "WB RGGB Levels Measured" values for "WB RGGB Levels As Shot" values will circumvent the sanity check that Canon applies to the temperature.
In either case, the "WB RGGB Levels As Shot" values need to be converted in
cr2hdr and fed into
dng_set_wbgain.
The alternate approach is to estimate the white balance in
cr2hdr, since we're looking at all of the raw data anyway. We would just need to mimic steps (1)–(3) and (7), and then feed the values into
dng_set_wbgain. It'd be very difficult to replicate steps (4)–(6) because we don't know what Canon's transforms and algorithm are.
Respect, I'd never have figured that out! I admit I still don't understand the difference between shooing 100/800 and 800/100 on 5d3 (and supposedly 6d), but I hope your calculations will go into cr2hdr asap as this is the last real issue with dual_iso.
Quote from: ayshih on March 22, 2014, 09:43:01 PM
The alternate approach is to estimate the white balance in cr2hdr, since we're looking at all of the raw data anyway.
Very interesting idea as you seem to think this might fix Canon's faulty awb "intelligence", but I'd vote to at least add a default option to make the dual_iso temperature/tint the same as normal shots for easy mixing both types in post.
@Audionut
its the nature of "looking good", its subjective..
mathematical accurate wb isnt always the best choice, neither from the body nor the raw-converter. indoor pictures often have two whitebalanced points :) so. i wouldnt care about fiddling with manual adjusting wb-values in dng/cr2-tags. we talked about it longer time ago for raw_rec. its ok, if its near the good wb-point. my 2 cent.
http://www.magiclantern.fm/forum/index.php?topic=6779.0
Okay, I just put in a PR for the EXIF-based solution: https://bitbucket.org/hudson/magic-lantern/pull-request/453/white-balance-fix-for-dual-iso/diff
On my 50D, it gets in the right ballpark, but if one ISO is significantly overexposed, the white balance can get biased. Still, it's definitely a lot better than the hard-coded values!
Folks should test this on different models!
Excellent work.
Quote from: ayshih on March 22, 2014, 09:43:01 PM
(4) Transform the "WB RGGB Levels Measured" values into a temperature ("Color Temp Measured") and a tint (not recorded in the CR2).
If it's not recorded, then it must be determined by the raw convertor. And idea might be to test various convertors and see if they produce the same tint value. If they all produce the same value, either, there is documentation describing the process of calculating tint, or the value is indeed recorded in the exif.
Will be a few hours before I can test your pull request on 5D3.
Quote from: chmee on March 22, 2014, 11:58:01 PM
mathematical accurate wb isnt always the best choice,
From a subjective standpoint, almost never :)
I do like to see an accurate WB from a color neutral target though. It provides a baseline. For some reason or another, I always tend to go to yellow with skin tones.
Quote from: ayshih on March 23, 2014, 01:21:20 AM
Folks should test this on different models!
The good news: on 6D with 100/800, the color temperature is near to the non-dual_iso wb.
The bad news: the tint is still the same and completely elsewhere with ACR, in this case magenta ... here are the samples, no artistic value but just out of my window :-)
original cr2: https://bitbucket.org/Marsu42/ml-aiso/downloads/IMG_8666.CR2
dual_iso cr2 same exposure: https://bitbucket.org/Marsu42/ml-aiso/downloads/DUAL8668.CR2
dual_iso cr2 -2ev: https://bitbucket.org/Marsu42/ml-aiso/downloads/DUAL8669.CR2
Quote from: Audionut on March 23, 2014, 03:56:12 AM
If it's not recorded, then it must be determined by the raw convertor. And idea might be to test various convertors and see if they produce the same tint value. If they all produce the same value, either, there is documentation describing the process of calculating tint, or the value is indeed recorded in the exif.
I suspect each converter has its own camera-specific profile to interpret its own temperature and tint from the white balance numbers. It's clear that the camera internal transformation differs from the ACR profile because ACR reports a different temperature than what is recorded in "Color Temp As Shot".
Quote from: Marsu42 on March 23, 2014, 09:13:33 AM
The good news: on 6D with 100/800, the color temperature is near to the non-dual_iso wb.
The bad news: the tint is still the same and completely elsewhere with ACR, in this case magenta ... here are the samples, no artistic value but just out of my window :-)
Thanks for testing, but it looks like my fix isn't doing anything at all with 6D files! You're still getting stuck with the default white balance (which translates to 5600/+20 in ACR). That's because your CR2 files are missing nearly all of the EXIF tags I've been studying, with the only one left being "Measured RGGB". I can extend the fix to cover this situation, but I just want to confirm that you aren't somehow stripping those tags. This exiftool reference table (http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html#ColorData7) suggests that those tags should be there.Edit: the problem turned out to be an outdated
exiftool
Ugh, I've updated the PR, but you're not going to like the results. According to Lightroom, the temperature/tints for your files are:
IMG_8666.CR2 5900 +8
DUAL8668.DNG 4400 +42
DUAL8669.DNG 5000 +48
The hard-coded values (5600/+20) just happen to be close to the real white balance, whereas trying to get the white balance from "Measured RGGB" is doing fairly bad here. For the 50D, my earlier calculations (http://www.magiclantern.fm/forum/index.php?topic=10265.msg107526#msg107526") showed that "Measured RGGB" was much worse to use than "WB RGGB Levels Measured" because the G channels (at different ISOs) would get averaged together, while the R and B channels were at different ISOs. It doesn't look like that's the case on the 6D, but it's hard to tell without the other tags!
For comparison of the effectiveness of the fix, when I can use "WB RGGB Levels Measured", here are some numbers from my 50D:
IMG_0689.CR2 5450 +13
DUAL0688.DNG 5700 -4
A little bit off, but certainly better than the hard-coded values (4850/+46).
I'd like to see some results from the 5D2/5D3 folks.
Your update gets close to the dual_iso CR2.
However, the WB of the dual_iso CR2 is different to normal ISO.
Also, auto WB in LR produces the same WB/tint values for normal ISO, and dual_iso.CR2, but is always different for the dual_iso.DNG.
5D3
Normal ISO
https://dl.dropboxusercontent.com/u/34113196/Dual-ISO/_46A9808.CR2
dual_iso
https://dl.dropboxusercontent.com/u/34113196/Dual-ISO/_46A9809.CR2
Quote from: ayshih on March 23, 2014, 04:01:29 PM
That's because your CR2 files are missing nearly all of the EXIF tags I've been studying, with the only one left being "Measured RGGB". I can extend the fix to cover this situation, but I just want to confirm that you aren't somehow stripping those tags. This exiftool reference table (http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html#ColorData7) suggests that those tags should be there.
Ah! My
exiftool was fairly old, and apparently couldn't read the white balance information on newer cameras (6D, 5D3, ...). With an updated
exiftool, here's the comparison of using three different tags to get the white balance information.
Marsu42's files (6D):
IMG_8666.CR2 5900 +8 (normal)
DUAL8668.CR2 4400 +42 (Measured RGGB)
4700 +29 (WB RGGB Levels Measured)
4150 +25 (Raw Measured RGGB)
DUAL8669.CR2 5000 +48 (Measured RGGB)
4700 +29 (WB RGGB Levels Measured)
4400 +27 (Raw Measured RGGB)
Audionut's files (5D3):
_46A9808.CR2 4350 +48 (normal)
_46A9809.CR2 4800 +45 (Measured RGGB)
3400 +42 (WB RGGB Levels Measured)
4400 +28 (Raw Measured RGGB)
My files (50D):
IMG_0689.CR2 5450 +13 (normal)
DUAL0688.CR2 ---- -- (Measured RGGB, not usable)
5700 -4 (WB RGGB Levels Measured)
4250 +15 (Raw Measured RGGB)
Quote from: ayshih on March 23, 2014, 05:40:59 PM
Marsu42's files (6D)
Doh, looking at the 6d/5d3 differences I now understand why the tint issue is such a huge problem for me while alex and other 5d3 folk don't seem that concerned.
As I wrote above, I'm completely puzzled what's going wrong with dual_iso tint and how it is computed from the cr2 tags so I can only hope someone else is smart enough to figure it out :-o
Edit: I do really hope this is just a metatag issue and there's nothing wrong with dual_iso itself on the 6d that cannot be fixed by a cr2hdr update :-\
PR updated with new logic. In brief, "WB RGGB Levels Measured" will be used if there is an indication that it preserves the dual-ISO behavior (50D), otherwise "Raw Measured RGGB" is used (everything else so far). Which tag is used is printed in the cr2hdr output (right near the end), as well as a warning message about a possibly out-of-date exiftool if it can't find these tags. So, here's where we stand:
Marsu42's files (6D):
IMG_8666.CR2 5900 +8 (normal)
DUAL8668.CR2 4150 +25 (Raw Measured RGGB)
DUAL8669.CR2 4400 +27 (Raw Measured RGGB)
--
default 5600 +20
Audionut's files (5D3):
_46A9808.CR2 4350 +48 (normal)
_46A9809.CR2 4400 +28 (Raw Measured RGGB)
--
default 5500 +19
My files (50D):
IMG_0689.CR2 5450 +13 (ISO 100)
DUAL0688.CR2 5700 -4 (ISO 100/800, exposed for 800)
--
IMG_0709.CR2 4800 +27 (ISO 400)
DUAL0708.CR2 4750 +27 (ISO 400/100, exposed for 400)
--
IMG_0707.CR2 4400 +21 (ISO 400)
DUAL0706.CR2 3900 +19 (ISO 400/100, exposed for 400)
--
IMG_0715.CR2 4850 +30 (ISO 400)
IMG_0717.CR2 4800 +28 (ISO 100, exposed for 400)
DUAL0714.CR2 4650 +26 (ISO 400/100, exposed for 400)
DUAL0716.CR2 4500 +26 (ISO 100/400, exposed for 400)
--
IMG_0718.CR2 4300 +23 (ISO 100)
DUAL0719.CR2 4000 +3 (ISO 200/100, exposed for 100)
DUAL0720.CR2 3500 +10 (ISO 400/100, exposed for 100)
DUAL0721.CR2 3400 -24 (ISO 800/100, exposed for 100)
DUAL0722.CR2 3900 *** (ISO 1600/100, exposed for 100)
IMG_0723.CR2 4250 +24 (ISO 100)
--
default 4850 +46
Just with these shots, this fix seems to work decently on everything but the 6D, but there needs to be more testing across a variety of lighting conditions.
Quote from: ayshih on March 23, 2014, 09:12:46 PM
Just with these shots, this fix seems to work decently on everything but the 6D
Doh (yes, I know I already said that) - let me know if you need any additional testing on the 6d, or maybe alex/1% might share some insight on if there's a problem with the metatags or dual_iso itself on the 6d...
More test images for the 6D would definitely be useful, with different scenes and different lighting. Perhaps there's something specific to that scene that is throwing off the 6D, and the other cameras would have trouble too.
I've added the results from more 50D shots to my earlier post. As expected, this fix tends to struggle when one of the ISOs is significantly overexposed (which, of course, is typically the case when dual ISO is used for shadow recovery).
Quote from: ayshih on March 23, 2014, 09:21:49 PM
More test images for the 6D would definitely be useful, with different scenes and different lighting.
Next batch, colorchecker with artificial light, normal cr2 and dual_iso (100/400, 100/800, 100/1600): https://bitbucket.org/Marsu42/ml-aiso/downloads/dual_iso_test_1_a.zip
I ran the 20bit cr2hdr with your latest commit on them, but and the acr "as shot" from the normal cr2 (3500/39) is still completely different from the "as shot" computed by the new cr2hdr (2250/24, 2500/18, 2400/16). Btw the acr "auto" values are about the same for normal cr2 and dual_iso.
It's just that in this case the dual_iso shots happen to look subjectively better because the normal cr2 shows the color cast of the energy saver bulb... but the point is that the dual_iso "as shot" computed wb still hasn't got anything to do with the normal cr2 "as shot" canon awb - and that's what it is about, isn't it?
Of course all these don't look *exactly* as they should in comparison to getting the correct temperature/tint with the lightroom wb dropper (2650/29), but this isn't to be expected anyway.
Last not least, in this cr2hdr there's a regression - the last scanline on the very bottom is broken and shows artifacts.
Quote from: Marsu42 on March 24, 2014, 12:38:34 AM
I ran the 20bit cr2hdr with your latest commit on them, but and the acr "as shot" from the normal cr2 (3500/39) is still completely different from the "as shot" computed by the new cr2hdr (2250/24, 2500/18, 2400/16). Btw the acr "auto" values are about the same for normal cr2 and dual_iso.
(You have a small typo; the first one is 2550/24.) I'm encouraged by how consistent the white balances are for the three dual ISO shots. I'm not surprised that it's so different from the normal shot; test shots should probably stick to lighting temperatures above ~3500 K. I'm not sure what ACR actually does when you select "Auto"; if it actually reads the "WB...Auto" tag, it applies additional logic.
Quote from: Marsu42 on March 24, 2014, 12:38:34 AM
It's just that in this case the dual_iso shots happen to look subjectively better because the normal cr2 shows the color cast of the energy saver bulb... but the point is that the dual_iso "as shot" computed wb still hasn't got anything to do with the normal cr2 "as shot" canon awb - and that's what it is about, isn't it?
Canon seems to refuse to accept a temperature less than ~3500 K for auto white balance, but reverse engineering their exact logic (i.e., step (5) in my list above) would be non-trivial. This difficulty would be present whether the fix is based on EXIF information or the raw data. So, at least for now, it's beyond the scope of this fix to get matching at such temperatures. But, on the plus side, this mismatch actually gives you a better white balance.
Quote from: Marsu42 on March 24, 2014, 12:38:34 AM
Last not least, in this cr2hdr there's a regression - the last scanline on the very bottom is broken and shows artifacts.
Hmm, I haven't looked at the 20-bit branch at all, but I've barely touched
cr2hdr.c, so it should be "easy" to track down the regression.
Quote from: Marsu42 on March 24, 2014, 12:38:34 AM
Last not least, in this cr2hdr there's a regression - the last scanline on the very bottom is broken and shows artifacts.
Yes, this is an error in the latest code form a1ex.
Reported by IliasG here (http://www.magiclantern.fm/forum/index.php?topic=7139.msg108163#msg108163).
Quote from: ayshih on March 24, 2014, 02:51:06 AM
I'm not sure what ACR actually does when you select "Auto"; if it actually reads the "WB...Auto" tag, it applies additional logic.
Based on observation, I would say that Adobe applies it's own logic.
Quote from: ayshih on March 24, 2014, 02:51:06 AM
I'm encouraged by how consistent the white balances are for the three dual ISO shots. I'm not surprised that it's so different from the normal shot; test shots should probably stick to lighting temperatures above ~3500 K.
Ok, so here's another proper batch sample in daylight with awb from both 6d and 60d. I shot iso 100/200/400/800/1600 once as a normal cr2 with proper exposure, then once dual_iso with iso 100 exposure (i.e. high dual_iso overexposed), then once with "under"exposure even for dual_iso for highlight safety. I didn't have time to look at the wb though, have to work trough the week...
FIXED ARCHIVE BELOW!
Quote from: ayshih on March 24, 2014, 02:51:06 AMHmm, I haven't looked at the 20-bit branch at all, but I've barely touched cr2hdr.c, so it should be "easy" to track down the regression.
I posted a bug description in the dual_iso thread.
Quote from: Marsu42 on March 24, 2014, 03:54:08 PM
Ok, so here's another proper batch sample in daylight with awb from both 6d and 60d.
For the dual ISO shots, I've labeled it such that the first ISO is the properly exposed ISO, so if the second ISO is greater, then there is overexposure going on.
Marsu42's 6D shots (uses Raw Measured RGGB):
100 5950 +10
200 5900 +11
400 5900 +10
800 5900 +9
1600 5900 +8
100/200 4650 0
100/400 4650 -1
100/800 4650 -1
100/1600 4700 +1
200/100 4600 -2
400/100 7800 -78
800/100 7800 -78
1600/100 7800 -78
--
default 5600 +20
Although the fix doesn't work well for the 6D, at least the results are consistent, even with overexposure. There does appear to be an additional problem with underexposure.
Marsu42's 60D shots (uses WB RGGB Levels Measured, like 50D):
(removed due to mini_iso changing the black level)
The fix performs spectacularly bad! I haven't dived into the actual raw data, but I noticed that the nominal black level appears to change with ISO: 64 at 100, 96 at 200, 128 at 400, 192 at 800, and 320 at 1600. Are you running
mini_iso or otherwise tweaking your black level? Or does the stock 60D do this? I wonder whether the changing black level is what is making the EXIF tags completely unreliable for this fix.
Also, annoyingly, "Raw Measured RGGB" is always "0 0 0 0" for these 60D files, so it's harder to guess at what's going on inside the camera.
mini_iso has an option to do that to the BL. It maintains the lowest BL, while still being large enough to capture the stdev.
Quote from: ayshih on March 25, 2014, 05:10:20 AM
Although the fix doesn't work well for the 6D, at least the results are consistent, even with overexposure. There does appear to be an additional problem with underexposure
Hmmyes, I guess that's why your fix wasn't working for me as I usually underexpose dual_iso for complete highlight safety :-o
Quote from: ayshih on March 25, 2014, 05:10:20 AMThe fix performs spectacularly bad!
Oh no, sorry for wasting your time - I indeed had mini_mo also copied to my 60d and then forgot about it... but thanks again for looking at the tint problem as this need a lot of trial & error work :-o
Link to fixed archive : https://bitbucket.org/Marsu42/ml-aiso/downloads/dual_iso_samples_6d_60d_FIXED.zip
Quote from: Marsu42 on March 25, 2014, 08:14:32 AM
But underexposing 100/800 should be about the same as proper exposure for 800/100, shouldn't it?
Depends how you are metering.
If you're metering 100/800 for ISO 100, and underexposing, you have ISO 800 picking up the slack. You're underexposed at ISO 100 (highlight safety), and half of the resolution is being scanned at ISO 800 (reduce noise in shadows). Note: You remove the electronic noise with ISO 800 (dual_iso), but dual_iso does nothing for shot noise.
If you're metering 800/100 for ISO 800, you should be applying a shadow priority. In this case, you may not know if the ISO 100 scan will capture all of the highlights.
Quote from: Audionut on March 25, 2014, 09:42:39 AM
If you're metering 800/100 for ISO 800, you should be applying a shadow priority. In this case, you may not know if the ISO 100 scan will capture all of the highlights.
Indeed, that's why I don't see any reason for high/low to be there anyway - as argued multiple times, you can always try to recover details from shadows with cr2hdr wizardry, but if half of the highlights are clipped that's that and this is visible on my standard furry shots.
Quote from: Marsu42 on March 25, 2014, 11:08:15 AM
Indeed, that's why I don't see any reason for high/low to be there anyway
I don't use it. But where shadow priority is significantly greater then highlight priority, I can see how it would be useful.
I like to look at the zebras for exposure. They don't lie.
I don't fully understand the maths (little reminder I am maths stupid), but changing line 582 of zebra.c as so,
Quoteint underexposed = ev_to_raw(- (raw_info.dynamic_range - 100) / 115.0);
Changes the underexposed zebras to around -9 EV. This is much more aligned with an acceptable noise limit in the shadows @ ISO 100, then the actual noise floor of the camera (SNR=1:1 = reported DR).
Quote from: Marsu42 on March 25, 2014, 11:08:15 AM
you can always try to recover details from shadows with cr2hdr wizardry, but if half of the highlights are clipped that's that and this is visible on my standard furry shots.
Here, you're in extreme highlight priority, including full resolution. Depending on how bright that detail (that needs to retain full resolution) is, you may still be able to get away with 100/200 or 100/400.
I would use zebras in this situation also. Look for the half zebras.
Needing 9 gazillion stops of DR means you have to use large ISO spacings (100/1600 for example). But the biggest jumps in noise reduction in the shadows, actually come with the next highest ISO. ISO 100/200 for example.
If you can use ISO 100/200, or ISO 100/400, and the zebras are showing the (wanted) highlights retaining full resolution, then why not?
Quote from: Marsu42 on March 25, 2014, 08:14:32 AM
Oh no, sorry for wasting your time - I indeed had mini_mo also copied to my 60d and then forgot about it... but thanks again for looking at the tint problem as this need a lot of trial & error work :-o
Okay, so with the latest batch of shots, all the black levels are ~2048 as expected, and all the "Raw Measured RGGB" values are nonzero.
Marsu42's 60D shots (uses WB RGGB Levels Measured, like 50D):
100 5100 +3
200 5150 -1
400 5150 -1
800 5100 -1
1600 5100 -1
100/200 4150 -11
100/400 4650 -16
100/800 4800 -28
100/1600 3150 -99
200/100 4200 -9
400/100 4700 -1
800/100 4150 -23
1600/100 2150 -94
--
default 5000 +11
The EXIF-based fix appears to give plausible but incorrect values up to a 2-stop difference in the ISOs, starts to diverge significantly in tint at a 3-stop difference, and then is completely off at a 4-stop difference.
Based on the results from these three cameras, I think this may be what we can typically expect from the EXIF-based approach: sometimes decent results up to a 2-stop difference in the ISOs, with effectiveness varying with scene and camera model.
I guess it's time to investigate the raw-data approach.
Quote from: ayshih on March 26, 2014, 04:08:50 AM
I guess it's time to investigate the raw-data approach.
Playing with a custom WB algorithm: https://www.dropbox.com/sh/uz75fw290v4n7v7/ASbJRAUXk-
- auto: this is ufraw's auto white balance (most likely a simlple averaging)
- graymax: this is my algorithm, which attempts to maximize the number of gray pixels; this is done by looking for a peak on a vectorscope in EV space, blurred and weighted towards daylight. The idea is roughly similar to this one: http://www.stanford.edu/~sujason/ColorBalancing/robustawb.html
Some of the raw files can be found here: https://www.dropbox.com/sh/sta87fj2pghv6o4/vPXNvbhZdJ
Most of them were taken from the dual iso thread.
Also worth reading: http://www.acad.bg/rismim/itc/sub/archiv/Paper3_1_2012.pdf
If this algorithm gets the WB pretty much right, this will be very useful for AMaZE (reducing highlight alias even more, since AMaZE relies heavily on correct WB applied before demosaicing) and also for the highlight compression (--soft-film). If this algorithm results in significantly fewer pictures that require manual WB tweaking in post, it should be a nice timesaver.
I don't know how LR does its auto white balance, but I guess Marsu would have already used that one if it was any good :P
Quote from: a1ex on April 11, 2014, 10:48:09 PM
I don't know how LR does its auto white balance, but I guess Marsu would have already used that one if it was any good :P
Actually ACR "auto" wb isn't that bad! For my taste it just usually lands a bit too much in the cyan-cold region (yes, my monitor is calibrated) so I seldom use it - but it's fine as a base for dual_iso shots with its currently broken wb.
If cr2hdr could emulate this ACR awb it would be perfect for most people, I guess this is about what can be done with a simple algorithm w/o trying to be as "intelligent" as Canon is and w/o reverse engineering what Canon does in camera.
Let me know if you need any help trying something out on ACR/LR, but I'm currently too busy to contribute anything else than a quick test and feedback :-o
I've just commited the code; maybe you can check if it works in ACR and maybe some comparison shots with ACR AWB would be nice. Indeed, this one is a fairly simple algorithm without any reverse engineering.
_46A0416.jpg (https://dl.dropboxusercontent.com/u/34113196/ML/WB/_46A0416.jpg) / Adobe Auto WB (4350k / +30 magenta). I would class this as pretty accurate, and by accurate I mean, the light source (afternoon sun) appears white. My personal preference is around 600k warmer.
I think Marsu42 uploaded a zip earlier with some color checkers, shot in varying light conditions. I know you have shown that a grey card is not 100% accurate, but it removes any personal preference (bias), from what should be an accurate (white = white, grey = grey) algorithm. JMO (http://www.urbandictionary.com/define.php?term=JMO).
The x-rite color checker, also contains patches, that are progressively warmer and cooler (not sure if Marsu42 captured those). This may be useful for producing a warmer preset. :-X
Quote from: Audionut on April 12, 2014, 01:14:11 AM
The x-rite color checker, also contains patches, that are progressively warmer and cooler (not sure if Marsu42 captured those). This may be useful for producing a warmer preset. :-X
Yes, I have captured the full x-rite - the cr2 files normal and dual_iso are in https://bitbucket.org/Marsu42/ml-aiso/downloads/dual_iso_samples_6d_60d_FIXED.zip
as_shot = --wb=graymax
auto = ACR auto WB
measured = measured reading from grey patch with WB tool.
2000k and 50000k are the limits of Adobe.
+/-150 tint is the limit of Adobe.
as_shot auto measured
indoor 2950 -11 2850 +0 3000 -9
indoor1 4400 +15 3300 +0 4900 +1
cloudy 5700 +2 6200 +0 5450 +2
sun 4700 +31 5200 +26 5200 +10
fluro 3550 +51 3600 +30 3500 +48
Flash.
as_shot auto measured
direct 5150 +6 4600 +0 6600 +3
diffuse 4600 +4 3750 +0 6450 -7
CTB 4700 +4 7500 +0 50000 +22
CTO 2750 +5 2850 +0 2900 +1
+green 5050 +79 4400 +30 5800 +85
SFX1 3000 -40 7500 +0 50000 -150
SFX2 2550 -1 2850 +4 2000 +13
SFX3 2950 -53 2850 +0 2000 -150
SFX4 4200 -8 3250 +0 5100 -20
SFX5 5750 +28 4550 +9 7350 +26
https://www.dropbox.com/sh/kqqswu894uxu5r4/WVVperRfh-
https://www.dropbox.com/sh/lrutvdhiqmwdwgb/DsPUrbs7E1
The SFX series were quite evil :P
Updated the vectorscopes with some funky graphs (Kelvin<->multiplier mapping ported from ufraw).
https://bitbucket.org/hudson/magic-lantern/commits/d53afebd9579
https://www.dropbox.com/sh/uz75fw290v4n7v7/ASbJRAUXk-
https://www.dropbox.com/sh/lrutvdhiqmwdwgb/DsPUrbs7E1
As you know, the raw vectorscope I'm using for finding the white balance is a XY histogram of log2(red) - log2(green) vs log2(blue) - log2(green), where I'm looking for a peak (that is, maximize the number of gray pixels). The overlaid lines represent the location of Kelvin/green values converted to raw multipliers (for AsShotNeutral).
If the Kelvin<->multiplier routines also match Adobe values, these routines will be very useful for converting Canon white balance from kelvin to AsShotNeutral multipliers. This was one of the promises of MLV: correct white balance metadata.
Now, I don't fully understand all this math and I'm not sure if these graphs make any sense. But at least the printed kelvin/green values seem to match ufraw's kelvin/green when you select Camera WB.
Notice the curves are camera-specific; they depend on the color matrix. Try ignoring the color matrix in the Kelvin routine (that is, turn these if (0)'s from kelvin.c into if(1)) and see how the graphs change.
I would also like to know the relationship between ufraw's green balance (which is simply a multiplier applied to the green channel), Adobe's tint and Canon's green-magenta WBShift.
Quote from: a1ex on April 15, 2014, 09:16:42 AM
Adobe's tint and Canon's green-magenta WBShift.
Yes, that would be quite interesting to know indeed, esp. as the "tint" matter is often left out of the equation and wb is only thought of as "color temperature" even with photogs who are supposed to know stuff.
Concerning your grey wb: Audionut seems to have more time so I won't duplicate his recent chart tests, but I tried a few dual_iso shots and it looks fine so far and makes soft film cure more usable - heads up!
Quote from: Marsu42 on April 15, 2014, 09:24:36 AM
Yes, that would be quite interesting to know indeed, esp. as the "tint" matter is often left out of the equation and wb is only thought of as "color temperature" even with photogs who are supposed to know stuff.
Indeed. When shooting in daylight you may get away with a neutral tint, but once you move into artificial lights, adjusting tint becomes essential.
With some lenses, even the dominant color of the background leaks onto the main subject. So if you have an animal in the middle of some green grass (you know this one better), you may have to adjust the tint towards magenta.
Also, from the graphs, you can notice the kelvin/green adjustment seems to be ill-defined, that is, you just can't cover the entire mutliplier space (with green normalized to 1) just with these two parameters. This doesn't matter on most practical situations, but only on extreme cases, like Audionut's color filters, or when shooting infrared. I have included an infrared picture in the test series, and its vectorscope looks like this:
(https://dl.dropboxusercontent.com/sh/uz75fw290v4n7v7/VkZdbFEYRD/f313851904-graymax.png)
Quote from: a1ex on April 15, 2014, 09:36:54 AM
With some lenses, even the dominant color of the background leaks onto the main subject. So if you have an animal in the middle of some green grass (you know this one better), you may have to adjust the tint towards magenta.
Thank the maker for ACR's wb adjustment brush, tint bleed becomes prominent after pulling down highlights which kills the smooth rolloff and exposes the color cast. Also in the flash shadows with high dr dual_iso the flash is usually magenta-ish, and this isn't adjustable with a cto filters that I usually have on my flashes... that's how I came to get to know the tint adjustment :-p
There is a small discrepancy in the white balance Temp & Tint values shown in Lightroom for a dual-iso converted DNG, compared to the equivalent normal CR2 image.
Example:
Type | Temp | Tint |
Normal CR2 | 6000 | +6 |
Dual-ISO DNG | 5900 | -3 |
The AsShotNeutral values are the same, so the white balance calculation in cr2hdr is working - at least for this image.
The difference is not very large, so it might not be worth the effort to fix; but I have found a way to make Lightroom calculate identical Temp and Tint values.
The solution is to include the ColorMatrix2, CameraCalibration1, CameraCalibration2, CalibrationIlluminant2, ForwardMatrix1 and ForwardMatrix2 values for the camera in the DNG file. It also requires setting CalibrationIlluminant1 to 'Standard Light A' and CalibrationIlluminant2 to D65.
I've tested this with cr2hdr 'classic' (5D3-123 branch), and with cr2hdr-20bit.
At the moment my fix changes the raw_info structure, which a1ex tells me will break compatibility with other things.
I can probably develop a fix without modifying raw_info; but I'm not sure it's worth the effort - is anyone interested in having the additional color calibration data in the DNG files?
Phil.
I don't see a problem pushing your changes to the 20bit branch. I think the idea is not to have your raw_info structure changes in the unified branch, that would lead to lots of complaining.
When the 20-bit branch will be merged back, the modified raw_info structure will not be funny.
What about updating the matrices via exiftool, at the end? May be a little slower, but we already call exiftool to copy the tags from CR2.
Quote from: a1ex on June 14, 2014, 06:13:32 AM
When the 20-bit branch will be merged back, the modified raw_info structure will not be funny.
What about updating the matrices via exiftool, at the end? May be a little slower, but we already call exiftool to copy the tags from CR2.
The version of exiftool I'm using (OS/X 9.63) doesn't understand the color calibration data from CR2 files - if it did then these tags would already be getting copied.
Maybe it's an exiftool problem on my system? Do you see the additional tags in your converted DNG files?
The idea I had for the raw_info struct would be to use a custom #define to allow cr2hdr to include the additional data:
int32_t calibration_illuminant1;
int32_t color_matrix1[18]; // DNG Color Matrix
#if defined(RAW_INFO_EXTRA_CALIBRATION)
// Include additional color calibration details in DNG file for cr2hdr
int32_t calibration_illuminant2;
int32_t color_matrix2[18];
int32_t camera_calibration1[18];
int32_t camera_calibration2[18];
int32_t forward_matrix1[18];
int32_t forward_matrix2[18];
#endif
Phil.
I thought I'd point out a relevant thread regarding the calibration matrices and illuminants: http://www.magiclantern.fm/forum/index.php?topic=10119.0
Quote from: ayshih on June 14, 2014, 09:04:26 AM
I thought I'd point out a relevant thread regarding the calibration matrices and illuminants: http://www.magiclantern.fm/forum/index.php?topic=10119.0
Thanks for that.
Didn't realise that the CameraCalibration matrices were actually camera specific (my 5D3 is very different to the values in that thread).
Removing these two matrices makes the problem worse than the current single matrix and illuminant - back to the drawing board.
Phil.
Quote from: philmoz on June 14, 2014, 06:25:04 AM
The version of exiftool I'm using (OS/X 9.63) doesn't understand the color calibration data from CR2 files - if it did then these tags would already be getting copied.
These matrices are not in the original CR2 - they are created by Adobe DNG converter.
Quote from: a1ex on June 15, 2014, 09:42:18 PM
These matrices are not in the original CR2 - they are created by Adobe DNG converter.
So is this hard wired into the DNG converter program or is there some other data in the CR2 file that it uses?
If the CameraCalibration matrices are specific to a particular camera (not model), then there should be some data in the CR2 file that Adobe is using.
Unless the different values I'm seeing are because it's a new version of the DNG converter.
Phil.
Right, CameraCalibration is specific to each body.
You can see some extra tags with exiftool -u -U (unknown tags).