Does it not get tricky if there’s no clear spike at the white point?
For the ‘data’ mode, I just use the max value of any of the three channels. No, it doesn’t discern real data vs hot pixels and such.
Really it’s more a tool to scale the data from its raw range, 0-16383 for 14-bit, 0-4096 for 12-bit, etc., to the 0.0-1.0 floating point range where the white point is anchored for rendition.
A histogram-based approach, discarding the top 0.1% of such could work, based on the very sharp boundary shown above:
|15267|182|0.000902%| 100%|
|15268|360|0.00269%| 100%|
|15269|166|0.00351%| 100%|
|15272|1|0.00352%| 100%|
|15282|5037568| 25%| 100%|
|15283|10074816| 74.9%| 75%|
|15284|5037731| 99.9%| 25.1%|
|15286|46| 99.9%|0.0967%|
Actually const-for-iso.
That depends a lot on image content. Probably a better guess would be 95% of max sensor data or alike. Don’t know yet how to do the best way.
Are you quoting code?! …
So dt has whitepoints which depend on ISO and camera model, is that correct?
If the exposure was good, that would be rather conservative. Why not use the same data as RT and correct that shared data if/when found to be wrong?
It could. But the data needs to be there in cameras.xml. For most models, I think there is only one value, and Canon coverage is probably incomplete…
I write on mobile so difficult to look up code. I think from memory rawspeed has one const value per camera only.
I am not sure, taking const-for-iso white point data read from some tables are good.
We should try to use exif data as for dng files. But those are manufacture specific not exposed yet via exiv2.
Some known MakerNote tags are, but yes, generally you cannot count on this and would have to carry out extensive testing for many makers and models.
I sometimes check what dt is saying against camconst.json and I’ve never noticed a discrepancy with my two Canons.
However that link you give is worrying, “specify ranges so they don’t overlap (0->399, 400->799, etc)”, that’s simply not how (Canon) cameras are engineered.
I uploaded this yesterday https://github.com/darktable-org/rawspeed/issues/375
M5 and 7D are complete. I will check 6D, 30D, D60, D30, 300D.
1 Like
Not in general, for 550D it’s just one white point but e.g. for 5DmIV there are iso range specific white points.
Check cameras.xml, there is also (undocumented?) iso_list, not just the range.
Thanks, I personally didn’t run into this issue until working on highlights as my camera has exif data…
I much rather have to work with a denoiser than to deal with highlight reconstruction.
I’m also someone who tries to teach people to forget the whole ETTR thing. It’s an old rule that is easy to f*ck up and isn’t needed with any modern camera.
Don’t get me wrong, more light helps to get a good picture. And people can be more ‘sensitive’ to noise than others… But one step too far, and you make editing the picture way harder for yourself. So always err on the side of caution with exposing. Much rather ‘a bit under’ compared to ‘a bit over’.
1 Like
Please correct me if wrong, but from the look of things it seems that there is some reconstruction. The sky is clipped, so couldn’t contain details otherwise, right?
Do you mean you didn’t do anything special, but you left the reconstruction at the defaults (which means it’s enabled)?
Dear Joris,
In DT 4.00 and in R-DT (3.9), there is no indication of clipping in the ‘raw over exposed’ indicator for this image. I would have to lower the threshold to 0.836 before I see the clipping indication. So I understand there still is some ‘headroom’ for the highlights. Right?
But with some fiddling I managed to remove the magenta cast. Here’s my take :
2014-05-30_19-47-01.cr2.xmp (16.1 KB)
I had to use a second instance of Color Calibration to work on the sky, and after that a second instance of Exposure.
Then I saw the link to the DT version of Jens-Hanno Schwalm. It took me a while before I found out how to build somehting from github, … but I’ve got the test version up and running, so I loaded the image and the same xmp. And I don’t see any difference. I must be doing something wrong. But what? how can i get that new HLR module working?
Thanks for your answer.
This thread is too long , unfortunately dt gets the whitepoint in rawprepare wrong, set it to "~12700 and see what happened. Blown areas are shown as blown with a nice msgrnta color. Use this as a starting point.
Aha! OK, I (begin to) understand. 