DxO and “highlight … recovery” are 2 incompatible things
Hi,
I didn’t want to intervene in this discussion before having run some tests. I tested the OP provided image, the sample provided by noname and some of my own pictures.
All that I can say is : problem confirmed.
It’s easy to reproduce:
Test #1
- Load the OP image in Lightroom
- Don’t do anything. The burned area on the metal plate is easy to see.
- The problem is easily fixed by using the Highlights slider.
Test #2
- Load a renamed copy of the OP file into LR.
- Don’t do anything and run the Transfer to DxO Photolab 7 command.
- In DPL, apply the optical and denoising corrections and export to Lightroom.
- Back into LR, try to eliminate the overexposed area with the Highlights slider : you immediately get the magenta color cast.
Although I regret that noname behaves so aggressively and impolitely, I have to admit he/she’s “correct” 
. Since noname appears to have a good knowledge of the Linear DNG format, one thing he/she could do is to more clearly explain the NEF to Linear DNG conversion process and how scaling is done.
Anyway, there’s obviously something wrong introduced by the code converting the initial data to a Linear DNG file and that should be fixed. I didn’t test with PureRAW but it’s not a surprise that the results are similar.
By the way, I have also noticed a similar problem with the Color rendering setting in DPL. Some areas that are initially not clipped may appear clipped and not recoverable depending on the choice made for this setting. For example, I have a Fuji X100 RAF file showing this problem when switching from DxO Camera Profile Fujifilm X100 (OK) to “From Camera (Velvia/Vivid)” (not OK). Absolutely no problem in LR/ACR with the same file.
However, this is another problem that I have to further investigate. I don’t want to pollute this thread, so I may start a new one about this issue.
format does not matter → DxO code clips regardless … and it also uses some erratic tone curve application on data range close to clipping that remains unclipped ( granted much less noticeable, but the principle is what matters )
one can only wonder what was/is a technical reason for that ? I can’t imagine one - but then I obviously have a poor imagination
I know nothing / zilch / zero about coding a photo application so feel free to laugh…
PhotoLab has always had the ‘protect saturated colours’ feature, which has become more complex with the arrival of their propriety wide gamut working colour space. Could that feature be linked to the erratic tome curve you are talking about?
oh, dear
"… from Hegel, Hegel from Bebel, Bebel from Babel , Babel from … " (c) a joke from the old country, simplified for the audience.
now, on a serious note… clipping (in DxO with unclipped raw data) happens before color transform even starts ( hence there are no “colors” to “protect” yet and then “protecting” is not to “clip” [ a bunch of “colors” into “one” ], but to [ attempt to] map [ them if they fall outside of destination gamut ] inside a certain destination color space … “compress” the source into the destination “color space” gamut)
and tone curve may or may not be before or after color transfORM in DxO code, but the case ( with erratic tone curve , not the clipping ) was illustrated on a neutral ladder… one can hardly imagine a color transform that will map that ( neutral patches ) outside of any gamut (of any colorspace that DxO can possibly use) … so the theory of “protect saturated colours” is not good, the “colors” are not saturated at all in the experiment
I said feel free to laugh, not be sarcastic and disparaging. It’s a pity you had to be so rude before you got to the important stuff because the rest of your post is informative.
1 Like
When opened as is in DPL, this file is heavily clipped with no possible recovery. However.…
I had a look at the metadata and noticed an inconsistency : the Whitelevel field is set to 16300 but the BitsPerSample field is set to 16. By default, the Whitelevel field is set to 2^BitsPerSample - 1. So, the actual value of whitelevel in this file is somehow surprising. Or is it the value of BitsPerSample ?
I edited the whitelevel field and set it to the default value of 65535 corresponding to the BitsPerSample value… I reloaded the file in DPL and bingo ! No more clipping.
So, it seems that DPL takes into account the whitelevel field and other data when remapping. The severe clipping that is done on the original file appears to be somehow logical. The other software tested (LR, C1, RawDigger, FRV, FIV,…) obviously just ignore the BitsPerSample field.
I don’t know enough about DNG to decide which behavior is correct, though.
1 Like
it is for a DNG generating software ( and its developer ) to set WhiteLevel as they wish for a purpose … if tag with an explicit value is missed ( not set ) then by default it is assumed to be 2^BitsPerSample - 1 . … in the raw DNG file you see the value for WhiteLevel tag was set by Adobe DNG converter, by people who (unlike people in DxO) know a thing or two about what to set in DNG files… no ? Adobe knows what the real white level was in incoming .ARW file and upon conversion to non-linear DNG correctly put it there as it should be for other software to use it in DNG file … for the purpose of verification in another thread I demonstrated that DxO will deal with original incoming raw and incoming DNG from Adobe DNG converter in absolutely exact manner ( for the purpose of Tiff and 2 flavors of DNG outputs = https://forum.dxo.com/t/clipped-highlights-but-only-in-photolab/37138/133
and yes the substance of the bugs in DxO PL code is
(A) wrong ( GROSSLY wrong) calculation of white level in incoming raws for some camera models ( like Nikon Zf in another topic )
(B) clipping below white level ( that DxO finds - correctly or not - another question ) in incoming raws ( yes if you specifically move white level far away from any image data - like you did DxO will not clip, but it clips unclipped data that sits just below it, like 1/2-1/3 stops below ) … in another topic about Nikon Zf camera where the bug “A” was discovered it was shown the same that injecting a sufficient number of pixels set to a certain DN will trick DxO into not clipping by forcing it to calculate white point sufficiently far away from actual data = https://forum.dxo.com/t/clipped-highlights-but-only-in-photolab/37138/ … no raw converter shall destroy image data upon ingestion of raw file in itself for a user to work with it if that data is present in raw file and lies below clipping point ( = not clipped ), but DxO does exactly that … we are not talking about data that lies 0.01 stops below clipping point - we can forgive such small beans… we are talking about whopping 1/3 stop or so… nowdays sensor designers will kill to get DR increased by such amount
(C) magenta tint effect resulting from incorrect ( incorrect in relation to what DxO writed as white point in output DNG ) demosaicked data scaling by DxO ( and that is with already destroyed data if that original data was close to the whitelevel calculated by DxO ) vs white point written in DxO generated linear DNG files