Thank you for the explanations. I did understand the first synthetic file. This comment helps me understand the second one. I still don’t fully understand but I should be able to figure out more when I have time (getting late now).
Funny, but Adobe DNG converter doesn’t find any RAW there. Or did I missed something obvious?
Just sorry for playing this sarcastic game. I try to be the ‘good’ one, @noname is obviously the ‘bad’ one, still looking for the ‘ugly’. We miss the point this way.
I examined the two files in PL, and in Affinity and Capture One. I see now what you are saying, essentially PL saturates the converted files at lower input raw levels than it has to. Even for the Z6 camera model.
It is not necessary to apply Adbobe DNG coverter to the two synthetic files.
They are both readable by PL. I.e., PL will treat them as raw files for Zf and
Z6 cameras, even though they are not in NEF files.
Exhibit A:
Exhibit B:
Isn’t that the simple answer ? … When a “native” Optics Module is available for this camera then (I confidently expect that) it will render this image correctly, without blown highlights.
The problem can be summarized as ‘premature data clipping in raw channels’.
In this particular example, OP provided us with two RAWs, taken seconds away, with the same settings and very similar lighting, for which one rendering was ok, the other being horrible (both taken with non-cpu lens). See Clipped highlights, but only in Photolab? - #44 by noname for preliminary analysis. Somewhat similar topic was in Weird tint to highlights , where data was clipped at 23k for ‘DNG export with NR and optical corrections only’, like in PureRAW, while it floated freely up to 51k for ‘DNG all corrections applied’ export. In that case a fully supported camera/lens combination was used (but ‘highly efficient compression’ was set, which is not the OP case, where standard 14-bit loseless was chosen). Both cases may have a common root cause, but that’s for DxO to investigate.
If you download both good and bad OP RAWs, you’ll easily see the problem. To magnify it, just choose Smart Lighting->Spot Weighted and mark some face area. You’ll see that whatever camera rendering you choose, the problem remains (for some reason a bit less seen for Leica Q).
I stand corrected. It’s over a month since I took these shots so I may be forgetting something. And thanks for your analysis Captain. That’s all very interesting.
I’ve been using PL since the first version, and it’s clear that they still haven’t improved this highlight problem…
Selective tone sliders are very poor in their operation (but this has been discussed many times already).
I like PL for its ease of use, Deep Prime (fantastic for my Lumix G9 and wildlife photography) and the fact that there is no need for cataloging (as a computer scientist, I like to keep the control over what is done).
I skipped version 7, but if version 8 does not correct the many problematic points, I think I will leave it there with them… And DXO no longer seems to listen to users…
1 Like
it is NOT - the matter was tested on cameras with and w/o optics modules , with and w/o applying them, same sh$t … and you do not seriously claim that DxO is a total cripple till optics correction module is available 
, do you ?
Adobe DNG converter was used to compress the synthetic raw files ( that were created in uncompressed form) for the sake of convenient downloading , it has no issues with them - just like it should - we use a convenient feature that DxO will open DNGs just like the donor raw files in their virgin / maiden form
FastRawViewer
2058
2059
.
RawDigger
2058
2059
from what I see…
-
In pic 2058 the illumination on the child’s face is more even than in 2059,
hence the difference in gradation. -
The white part on the box has influenced the statistics (histogram).
-
While both pics were taken with the same settings,
the face in pic 2059 is a touch brighter. -
In pic 2059, where PL7 signals overexposure,
RawDigger shows white (= no more texture).
it does not show white there … check the numbers, I posed them above in the topic … rawdigger is an instrument for data analysis by numbers not by your eye
yes, saturates, clips, destroys, obliterates, etc
so we count 3 bugs
(A) incorrect detection of true camera model/nominal iso/etc white level-white point- clipping point-sensor saturation point ( per channel if needed ) - for some camera models ( thank you OP again for producing raw files so clearly illustration the matter )
(B) destroying unclipped raw data before or during demosaick stage - that is regardless of “A”
(C) generating linear DNG output (NR/Optics option at least) with incorrect data for use by apps further in processing pipeline (demosaicked raw data scaling vs declared white level) - that is direct result of “B” and possibly also “A” ( may be not though - too lazy to check ) - that is what manifests itself as “magenta tint” or “magenta skies” later down the road, but thanks to “C” we discovered “B” and thanks to “B” + raws shared by OP we discovered “A”
now as far as I remember there was a claim that DxO fixed “magenta tint” issues for some Fuji camera model ( that is “C” from above ) … we need to check that for that camera model they also fixed “B” ( not sure if there was “A” there like we have for Nikon Zf )
so much for the “best in class”( unless there was a fine print like “* class of its own” ? ) and “bespoke testing” of camera/lenses raw files
I always check my pics on a calibrated screen (set up to 80cd/m² and contrast limited roughly to 500:1 for printing) … not by numbers.
The question could (should) be how to avoid “tone demolition” [in German: Tonwertabriss] or in other words, to keep a smooth gradation. To have pure white in the pic is no problem as long it represents the highlights and we do not have a sharp separation to the next visible tone.
For further investigation it could be interesting how camera plus raw-converter react at lower ISO settings, e.g. when set to 100 ISO instead to 3200 ISO.
Hi Wolfgang – although the subject captures are not optimally exposed, they are not edge cases either. We’ve all been there. Putting the spot exposure meter on the cheek area and lowering ISO, etc. would probably have resulted in a better capture. But let’s not shoot the messenger. Other apps have shown that there is some useful detail / color data in the areas obliterated by DxO PL. Worrisome too is that accumulating evidence suggests that the problem may not be specific to this camera.
it does not matter for the topic , rawdigger data ( the numbers ) shows that there is no clipping
as noted multiple times already - do not do ETTR ( intentional or by error or by chance ) if the intent is for raws to be processed in DxO PL or poorraw till the bugs are fixed … other apps like ACR or C1 'd have no issues to deal with that kid’s face as it was shot or even more exposed still
1 Like
noname : I do not equate optimal exposure with ETTR these days, but I do agree with you.
Yes, ETTL and use deepprime 
Problem for DxO is they’re somehow stuck with this bug:
If they fix it, there’s a loss of compatibility with the work already done with the current buggy versions.
Unless they leave a Bug/No bug compatibility button …
1 Like