Neither does DPL 
I was just worried if I can get hit by the problem and it seems it’s not the case. Over.
as promised = https://app.box.com/s/ige13nac8hlp1hyj61sc01sf3cx0me2t
this is a raw file with a whopping ( obviously ! ) 1536-steps greyscale wedge
top-left corner a patch @ black level
bottom-right corner a patch @ white level
background @ white level
a normal raw converter like Adobe ACR/LR will display 1535 distinct patches ( whitelevel on whitelevel naturally blends to background always, so bottom-right corner patch is invisible in principle )… now check what DxO demosaick will do , that is how many patches its famed demosaick / will assign blame to it for now / will be able to get ( start with no corrections and WB = as shot )
how much data is lost ? close to 1/2 stop of data before clipping rendered into oblivion… A way to go, DxO… 
illustrating that ACR does not clip anything that is present in raw ( 1535 patches delivered )
neither does C1
rawdigger says it is all there
Thank you for this illustrated demonstration.
Do you know why FRV (v2.0.7) also clips (but much less than DPL)?
I assume you have also tried it with an uncompressed version. Formally DPL does not support compressed or edited files generated by Adobe DNG Converter – just not to be possibly diverted by another bug.
Looks like an obvious case for escalation to support.
@slgcjt – does your problem appear also with TIFF exports (if TIFFs are acceptable for your workflow)?
you mean why FRV does not show last 7 patches ( one in invisible, so 6 → which is ~1/48th of a stop to clipping - see RD screenshot that shows first clipped patch vs whitepoint )
I do not know, but you can ask the authors ( make sure to give the link to the raw file ! ) - I bet Alex will answer you in 24-48 hours given the weekend and time difference vs Russia
it was escalated many times - that “magenta skies” is direct result of this matter … you can’t fix “magenta skies” effect in a genuine maNNer w/o fixing the underlying bug … may be instead of fixing the matter in general DxO was/is ( if at all ? ) patching the code for camera model by camera model [ case by case ] ( like somebody complained about a specific camera and DxO fixed the code only for that camera model ) … may be their code is so bad that it works that way [ can only be fixed for each camera model individually instead of just in one place that takes care for all cameras ] and they are too “busy” to go through the code for each and every camera model
This was tested in house on uncompressed, lossless compression was added for convenience ( faster download for curious observers, as lossless compresed is 10+ times smaller )
As for edited files - it is not edited , it simply has image data ( sensel’s DN ) replaced in situ
and PS : not only 1/2 stops of data before clipping will be annihilated by DxO code… certain ill effects with how DxO applies tone curves will start happening a bit more than 2/3 of a stop before clipping ( tone curve applied to not yet clipped data looks like some death throes across last 1/6+ [ 2/3+ - 1/2 ] of a stop before heart monitor flat lines )
turns out FRV does not clip, here we go - I manipulated with some FRV settings to force it to display missing patches, so no clipping in FRV either
PS: in FRV preferences I changed “Use Monochrome mode for Bayer images” to “Always”, a bit of a hack - but shows that FRV does not clip
Today I found the same problem with nefs from Nikon Zf 
welcome to the club
@Wlodek TIFF exports don’t work for me because of the highlight and shadow recovery as compared to DNG
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