Clipped highlights, but only in Photolab?

Thank you @noname!

Thank you for the intro to RAWDigger. I will read the manual and try to learn more.

If I understand the lesson well enough…
Photo 3 shows that only a few sensels on the main bird (photo subject) are truly “saturated” at the 16383 (2^14) value, so not a “bad” result.
Photo 2 shows the saturated areas at the pop can and these also show up as overexposed in both DxO PL and Adobe RAW, so consistent results between programs.
Photo 1 shows an area of “highly-exposed” sensels that will be difficult from which to extract detail.

AdobeRAW and DxO PL appear to set the “white point” at the 16383 value.
And, it appears that DxO processes the raw data as expected given the RAWDigger results.

So: not impacted by the DxO issue with the Nikon files.

it is quite possible that for Sony A1 model DxO code has everything OK when dealing with ARW - but we can’t test properly (so far) as DxO code does work differently with A1 DNGs ( unlike Zf ) … so we can try to find why, but no success is guaranteed… I also tested in DxO 6.9 - same difference…

PS: post some uncompressed Sony A1 raw file just in case - any content is OK

Here’s a link to some quick “test” photos from this morning.
Test Photos

All photos shot at f/6.3, 1/800sec, auto-iso with center-weighted exposure.
-Geranium photos show color and no overexposure at +2
-Truck photos show +0 to +3 with center weight on dark window or on brighter white door panel.

My observations…
-should run the test again with camera on tripod, better target showing dark and light areas, and specific iso step changes, not auto-iso.
-focusing on darker vs. lighter resulted in ~2.5 stop difference
-have about +1 stop latitude when focusing on a light area
-have about +2 stop latitude when focusing on a dark area
-not clear on effect of reflectance from chrome.
-Unexpected result - max green values were higher at 2500 iso vs. 3200 iso. No idea why - perhaps there is a built-in multiplier or sloppy shooting.
The +1 / +2 stop latitude is about what my experience suggests when out shooting, but this may be confirmation bias.

I still need to learn how to best take advantage of this latitude in PL when trying to get the closest to “perfect” / or push “ETTR”.

Thank you!

I suggest you have zebras indicator on your camera. set it to 100 or 100+ and depending on how you shoot, lets say you set it to P mode or Program mode, you just dial in the exposure compensation and let the camera do the rest. I see this is shot on Sony, I use a6300 and I don’t think I’ve had issue with lost highlights once. Super easy to dial in as much as you need. If you shoot too bright scene simply use exposure compensation and watch the zebras. Should not be a problem. If you expose a bit lower, it should not be too much problem cleaning up the shadows with DXO DeepPrime or DeepPrime XD. Like I said, unless I wanted blown highlights, its not a problem to dial in the correct exposure.

Thanks.
The subject of the thread was false clipping in DxO PL when using some Nikon cameras (raw file types). I also saw some differences in my Sony files so submitted a photo for review.

Based on these and previous photos, it appears that DxO handles Sony highlights “properly” in both the uncompressed and lossless compression modes. Your comments seem to support that conclusion. So not relevant to the Nikon issue.
@noname suggested I submit additional photos to further review PL’s handling of Sony files. Hence these photos.

Along the way I learned something about RAWDigger and how to help me dial in highlight limits.

As for camera setting… I prefer manual ss and aperture, using auto-iso or manual override based on the blinkies/zebras. I have my “blinkies” setting at 108+ trying to use some of the built-in headroom to best expose for the highlights (ETTR?). Mostly this works, and I can often get another 1/3 or more stops even with blinkies active at this setting. Sometimes I cannot. An example of this situation was the very bright white Whooping Crane photo submitted in the earlier post. I pushed the exposure to get more out of the balance of the scene but hoped the white bird stayed within the limits. It appeared to work, but I could not get much texture out of this brightly exposed bird. @noname’s comments and RAWDigger analysis of this photo, while not relevant to the Nikon issue, helped me better understand why I got the results I observed.

Sorry, I do not use “P” mode - ever. As amazing as these cameras are, they do not “know” the photographer’s intent so would not know how to adjust the setting for the intended photo. IMHO, that’s my (the photographer) responsibility.

2 Likes

Could you tell me what this means?

George

Are they exposed very close to raw overexposed (very close to full sensor “saturation” in some places) ?
This is where the photolab bug happens.
It seems only rawdigger can check this without any doubt.

more interesting question is why for this camera (Sony A1), DxO does not work identically for ARW and DNG …

I tried Z9 - there DxO code works identically…

R = rawread(‘z:\DSC_0341-NEF.dng’);
D = rawread(‘z:\DSC_0341-DNG.dng’);
isequal(R,D)
ans =
logical
1

Sony cameras show overexposure (OE) with blinking (white/black) areas in the viewfinder (Zebra stripes). I learned the general industry term as “blinkies” as a way to set in-camera exposure based on the highlights. @Joanna has explained this method in other threads.
In the Sony A1 menu, the setting is Exposure>Zebra Display>Zebra Level.
Sony Zebra Display
You can google videos explaining this tool/setting.

In my unscientific testing and recommendations form others I found I can often get away with a bit more exposure hence raising the default to 108.

When reviewing in post, each program I use (or try) sets the OE warnings in the histogram a little differently based on what appears to be a “safety margin” for how the program processes these highlights. This is my “guess”.

While this thread was about a specific Nikon issue, the question as to how PL and other programs process the same RAW highlight data was raised. So I posted a Sony example for comparison. As a result, @noname was kind enough to point me in a direction I hadn’t considered to better understand my confusion on how these programs process the data.

As to how to best set my exposure in the field for extremely white/black objects such as the Whooping Crane, I am still learning. This photo shows a few OE areas on the bird’s body and a few UE areas on the head. This is perhaps a subject for a different thread or forum.
I settled on Sony’s RAW lossless compressed format for my photos trying to get the most info in as small a file as possible.

From @noname feedback, DxO PL appears to handle this RAW format properly. I am satisfied.

Thank you!!

blinkies are blinkies, zebras are zebras - even when they serve the same purpose ( and can be repurposed ) they are different … some cameras have both - blinkies are for stills, zebras are for videos

@noname
Keeping this thread back on the file format questions.
I don’t see DNG as a native format with Sony, so not truely a “native” RAW format. Here are photos with the various in-camera RAW options to compare. Uncompressed, 3 levels of lossless, and compressed.
RAW File formats

Sony uses the zebra term for still photos too.

I did not make any proper tests, I am just saying that it seems that for A1 camera model if DxO code deals with ARW it might possibly be written properly ( that specific part ) … ideally somebody can shoot greyscale gradient that covers 1 stop gradually crossing into clipping and then investigate that raw… may be display such gradient on your monitor, defocus the lens ( we are not interested to see LCD panel pixels ) and take bracketed shots to make sure there is at least one with gradient image well below clipping on one side and fully clipped on another side and then post raws …

may be because they simply do not have bona-fide blinkies ( real time in EVF, not post shot review )

what matters is how raw converter deals w/ it … so far all raw conversions we explored were identical bit by bit across all image frame … so DNG = (for our purposes) what camera firmware writes… A1 is the first camera model where I see the difference in DxO code processing ( granted I did not explore hundreds of camera models )

PS: of course we are not talking about any lossy compressions…for experiments we do uncompressed lossless DNG conversion using current Adobe DNG Converter

Actually, the zebras are in the EVF. That’s how I adjust exposure.
Here’s the back screen, but same in EVF

1 Like

yes, I have an idea as I still have old A7R2… but I really prefer blinkies for stills vs using zebras… plus UniWB and other settings to use wider gamut and flatter tone curve… but off-topic it is…

DxO ceases to am(a/u)ze me not !

A7R2, display a smooth greyscale gradient, defocus, shot

ARW = https://app.box.com/s/m9aatrwfygxhy5qtcco7qzdfdxv5m1et

DNG = https://app.box.com/s/mmc1wng7u3778g0af2ppdvg71h86siag

DxO PL7.4 converts both to linear DNG ( classic way = NC/DOCO )

all is good, both clipped where shall they be clipped and identical

image

A = rawread(‘z:\RAW01384-ARW.DNG’);
D = rawread(‘z:\RAW01384-DNG.DNG’);
isequal(A,D)
ans =
logical
1

me, being a naughty pronoun ( obviously ), can’t stand that situation …

so as usual let us dope the image with some DNs = 12000 ( which is below max DNs for all RG1G2B channels )

R = Tiff(‘z:\RAW01384.DNG’,‘r+’); setSubDirectory(R,getTag(R,‘SubIFD’));M = R.read(); M(2500:2510, 7300:7310) = 12000;R.write(M);close(R);

that is 11x11 sensels in middle of a big area where green channels and blue are clipped … we unclip them

OMG, now DxO PL goes mad …

image

So now injecting few sensels with values below normally detected clipping will result in this trouble ( remember with Zf raw that started this topic we fixed a mess by injecting few sensels close to real clipping point - now we create a mess by injecting just few sensels well below real clipping point ) …

but if we further lower down the doze of the dope DxO recovers :grinning:

R = Tiff(‘z:\RAW01384.DNG’,‘r+’); setSubDirectory(R,getTag(R,‘SubIFD’));M = R.read(); M(2500:2510, 7300:7310) = 11000;R.write(M);close(R);

image

I’m not sure what all those numbers are supposed to represent, but I see no problem with DXO. Details can be recovered on both ARW and DNG. What is the problem exactly. And please leave your ego at the door and speak in plain English. On both images I reduced exposure by 4 stops and R,G,B show 100 at the lightest spot. Where do you see clipping in DXO PhotoLab?

@MSmithy , the OP’s image of the child with the marker looks as if the child had a fever and was sweating accordingly. The glow and the burnt highlights can’t be corrected in PhotoLab, while other apps show a perfectly lit portrait of the child.

Any other image, manipulated or not, can show whatever it shows, but feels irrelevant compared to what was discovered in the OP.

:person_shrugging:

1 Like