Clipped highlights, but only in Photolab?

DxO PhotoLab
50

BTW - thank you for the tip, now we can investigate this camera model on synthetic raw file just to be sure that DxO fixed white point detection/calculation for that camera model AND also does not clip unclipped data close to it !

also we shall test a theory about wrong WP calculation by filling the ( ALL of it ) frame w/ data well below clipping point for the sensor and then filling with patches from black level up to that level for a Zf … will see if we can tip DxO code to make an error

if I have time more time this evening

51

As you can see from the attached examples, I have no real issues with overexposed photos up to about +2EV. One shouldn’t expect medium level consumer camera to have more headroom in highlights.

Test:
PL7.4/Win11.
Nikon D780 FW 1.10, AFS Micro 60/2.8G (non-cpu 50/1.8 in OP), @f/4 (f/1.8 in OP), ISO 3200 (like in OP), AWB, matrix metering, A-mode.
Room lighting, 2700K 95 Ra LEDS (but never seen spectral data), some color casts.
Subject: one of those color checker gadgets I’ve never taken seriously, 10y+ old, so colors may be quite off the original. Perhaps too flat in DR and unreal scene for a decent test, but still I found it useful.
The jpegs were generated by PL7.4 from NEFs taken with 0 or positive exposure compensation given in the filenames (EC=0, EC=+1EV, …), exposure corrected by the same amount in PL (although the units might slightly differ). WB was corrected by probing the square below the black one in the top-right corner. No other PL settings were changed, in particular no NR or optical corrections were applied. The jpegs were made with 50% quality but that shouldn’t matter.

RAW files reported LightValue 5.6, 4.6, 3.6, 2.7, 1.6 respectively (in OP it was 3.7),
shutter speeds starting with 1/100 sec and changing as expected, RedBalance=1.2, BlueBalance=2.2. (in OP these were 1.726 and 1.336 respectively – daylight).
Hence the green channel was blown out first, then red, and the blue was quite persistent.

I have a habit of NOT taking photos with key information DR too wide,
but the OP photo certainly doesn’t fall in that category.
I hadn’t yet time to look at the “good” photo.

Bottom line:
The problem, which looks real for OP, seems to be specific to some camera/lens/settings combinations.

Side remark:
CO (short for Captain Obvious, to be sure) enthusiastic generalizations seem to be too premature, if not simply wrong, but he’s obviously right in the OP case, at least to me.

D780_4417_EC0
D780_4417_EC01920×1277 183 KB

D780_4420_EC1
D780_4420_EC11920×1277 169 KB

D780_4423_EC2
D780_4423_EC21920×1277 166 KB

D780_4426_EC3
D780_4426_EC31920×1277 164 KB

D780_4429_EC4
D780_4429_EC41920×1277 144 KB

52

OK, here is ZF synthetic raw = https://app.box.com/s/qg4ji6cmpayii8plqgxqkoebtj1pdu51

I intentionally make maximum raw values in raw file even less than in OP’s raw file ( _PAP2059.NEF ) =

image
image1354×1121 26.9 KB

image
image1642×1250 142 KB

as you can see max raw values are whole 1+ stop below true clipping for Zf

and what do we have for this camera model Zf in this raw ? DxO as expected promptly ( A ) makes an error in estimating what is the white level / clipping point for raw data, assumes wrong number for that and then promptly ( B ) destroys raw data even further below this wrongly calculated white level / clipping point ( destroyed data is located 2 stops and onwards below actual white level / clipping point )

53

first thing first… if no clipping in raw channels the shot is NOT overexposed

and then OP has real issue with ~2/3 stop underexposed raw shot :innocent:

54

I do not see raw files … no raw files → empty words … are we in a violent agreement on that part ?

55

@noname, I can’t because I don’t know enough, but perhaps you can explain the following:

When using the colour picker under HSL in PhotoLab on the area that is of interest here and looks white on screen, it selects a red/yellow range.

If the image is opened in Darktable and:

  • demosaic is set to “photosite color debug” (EDIT: just noticed also happens with other methods. Darktable was not rendering the whole image sometimes, so I didn’t see anything)

  • “Visualize clipped highlights in a false color representation…” enabled

  • threshold set to around 0.6 or lower (with the default method or segmentation based)

you can see something happening in the problematic area (on the marker pen it starts with a higher threshold):

37138
37138845×518 72.4 KB

56

(A) I pray to RawDigger - it something is not clipped in raw channels then it is not clipped in raw channels and whoever clips and destroys that data shall be promptly tarred, feathered and burned on the nearest stake ( slowly )

(B) I export from DxO PL after applying NO CORRECTIONs ( for the purpose of this investigation ) preset to DNG with NR+Optics Corrections only ( and I disable them both for the purpose of this investigation ) - if the data present in the source file is destroyed in that linear DNG ( see screenshot below ) then whoever clips and destroys that data shall be promptly tarred, feathered and burned on the nearest stake ( slowly )

image
image1354×1121 26 KB

(C) I have no clue what our talented open-source komrades do in DarkTable with raw data, but if they do the same as DxO PL code does then whoever clips and destroys that data shall be promptly tarred, feathered and burned on the nearest stake ( slowly )

57

Perhaps the fact that enabling “Visualize clipped highlights in a false color representation” under “highlight recovery” shows this area on the skin (and marker pen) provides one.

58

I do not know what they do , so no comment … the data in OP’s original raw was not clipped not in a single raw channel on the face - so whatever they do if they intend to say that there was any clipping in raw in that facial skin area then they shall stop (writing the code)

59

Yes I can see that the problem is triggered by the camera model declared in the NEF file, and not by the color profile used for processing.

For example, if I processs the original _PAP2058.NEF file in PL, it shows blown highlights. I can change the DxO PL setting Color/B&W Rendering
to another camera model. Changing to Nikon Z6 does not remove the blown highlights.

Whereas, presenting PL with the edited NEF file where camera model is
declared Z6, does remove the blown highlights.

60

for Z6 (mk1) raw files DxO might be properly calculating where the clipping is but still does clip/destroys unclipped data below that point ( last 1/3 stop of data below clipping is eliminated )

image
image1359×1163 25.6 KB

Z6 synthetic raw file to illustrate that DxO PL still clips = https://app.box.com/s/tff3qibgs2mxh7yxd8x1u61rz9d9akix ( maiden file = https://www.dpreview.com/sample-galleries/8048435192/nikon-z6-sample-gallery/2515224383 )

61

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
62

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.

63

we shall agree to disagree … I am not sure what is the issue to share the raws , but it is your call …

64

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/ !

65

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?

66

and that was the whole point of the exercise ( that the maximum observed in raw data is well below the true clipping point )

67

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

68

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 …

69

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).