I’ll read this thoroughly once with a few “mmmhh” and “aha” and forget most of it in a couple of days. Perhaps you can gain more from it:
1 Like
John,
I think you should make a call to DxO support and provide them with both RAWs. The key question is why both photos are rendered so differently, although the light level was the same, camera settings equal, just a slight difference in the scene. It is the best example of this problem I’ve seen so far, at least for Zf., which should really alarm them. It provides very useful input. Tell them also to try Smart Lighting, Spot Metered on a face area to get even more shocked, and a shock therapy is probably what they need.
Well, if you are not able to make conclusions from the published jpegs, sending RAWs would be rather useless. Please concentrate on explaining the differences in rendering of both RAW files provided by OP, which is a real problem. It’s where you can show your competence, with kind respects. I’m interested in this subject purely pragmatically, so I’ll not dig into all data details.
we shall agree to disagree … I am not sure what is the issue to share the raws , but it is your call …
Tell them to fix the issues for ALL CAMERA MODELS with (A) clipping point detection / I hope they understand, at least whoever still left there after the unfortunate events, that it is (1) per camera model and (2) per nominal ISO - might be different based on that and (3) might depend on something else too … if they are not able to do detection and correction in the code themselves - they can always outsource that to Adobe DNG converter … run the files [ we assume the have all those raw files from the bespoke camera + lens testing ], pickup what senior komrades in Adobe put in there → profit / and (B) unclipped data destruction … OR ELSE /we continue the whining here/ !
I’m sorry but I’m not sure I understand the two synthetic raw files.
The first one is named ZF=486.dng. In rawdigger the maximum value in
all channels is 6938. This file should NOT show blown highlights when
rendered, but in PL, it DOES show blown highlights. Camera model=Zf.
The second file is named Z6=600.dng. When I look it rawdigger, it shows maximum 14512 in each channel, and moreover rawdigger says 54.8% overexposure in each channel. So for this file, I would expect to see blown highlights when it is rendered. Camera model is Z6.
Am I missing something?
and that was the whole point of the exercise ( that the maximum observed in raw data is well below the true clipping point )
background between patches is set to clipping point on purpose … that DxO PL still clips data that is not clipped, even when it can clearly see how far sensor can be saturated
where do we start ?
that was a rhetorical question → so you just have to either trust the prestidigitator or get up to speed on your own …
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