PureRaw + Fuji X-T5 + Lightroom = purple in highlight

Thanks.

first check in FRV:


Then in PL export RAWDNG ( optical corrections only)
DNG lineair including correction and then expolore/view in faststone viewer

then PLv6:
it’s more “black all channels”


Well now we know CA correction in the tool doesn’t aplied in RAWDNG.

Some how there is a disbalance in the channels near clipping and clipped.


This difference could be your problem.

I’m sorry but I can confirm that there is absolutely no recoverable detail in the majority of the sky, as shown by @OXiDant in FRV and PL6.

And, as I have said before, it doesn’t matter what software you use, you will never get anything useful out of it.

Not only is it vastly over-exposed, the distant trees are not even sharp, explained by your use of an aperture of f/2.8, which has severely reduced the depth of field. to just the foreground trees.

I notice you have used multi-zone automatic exposure, which is never going to end up great. It took an average from the bright area and the dark area and made a best guess. But, then you set the exposure compensation to +1EV!!! This then increases the exposure even more, thus compounded the problem.


You really need to go back to the basics of how to take a photo. Please don’t take this as an insult but, are you new to photography with a real camera rather than a phone?

If you can give us some idea of your knowledge level, then we can suggest how to improve the reliability of what you are doing.

The question of this topic is not “how to take photo with highlight in the sky?”.
The question is “why I have purple in highlight with X-T5 DXO and LR ?”
OF COURSE I know that the photo is BAD, not focused and overexposed. But this is not the question.
The question is technical, not artistic.

Of course in good photo, I underexposed to be able to recover white. But even with a good exposure, a purpule variation appear sometime.
This BAD photo is to accentuate the issue.

In that case, you should know better. Any over-exposure provokes a “marker” colour, which will vary according to the software used.

As we have now said several times, Adobe uses purple and PhotoLab uses grey.

To repeat, the marker colour is there because the image is irrecoverably over-exposed.

i have just looked over the spec for your camera and it looks amazing but, I get the feeling you are relying on too many of the automatisms it provides rather than working in either semi-automatic or even manual mode, which will give you a much better chance of avoiding such problems.

None of the software you have said you use is at fault. They are doing what they were designed to do.

The marker colour isn’t part of the image, it is an artificial colour used to show you where you went wrong.

Your explanation doesn’t justify WHY the issue is only with X-T5 and not X-H2S, X-T4, X-T3 and X-T30.
The “marker” like you said, shouldn’t care of the camera.

Even a god of photography has sometime burned highlight in his photo and not depending on his shooting mode !
When the subject is more important than the bakeground or the sky for exemple. In this kind of case, purple is not acceptable. Burned highligh should be white or gray if we push to hight the slider : but never purple.

as I can see based on conversion of RAF to linear DNG done by (1) Adobe tools (2) Iridient (3) DxO PL6.9

DxO does not scale raw values properly… while both Adobe and Iridient do scale clipped values to ~max 16 bit value in linear DNG , DxO does not scale anywhere to clipping… as a result Adobe converters do not see clipping in linear DNG produced by DxO PL…

It is a clear case of DxO not generating a proper linear DNG file

1) Adobe linear DNG == GREY

0xc61a BlackLevel : 4080 4080 4080
0xc61d WhiteLevel : 65535 65535 65535

actual raw data reported by raw digger from the spot with all 3 channels “clipped” (same spot for all 3 linear DNGs)

R = 65516
G = 65535
B = 65535

2) Iridient linear DNG == GREY

0xc61a BlackLevel : 0 0 0
0xc61d WhiteLevel : 65535 65535 65535

actual raw data reported by raw digger from the spot with all 3 channels “clipped” (same spot for all 3 linear DNGs)

R = 65521
G = 65525
B = 65522

3) DxO PL6.9 linear DNG == MAGENTA

0xc61a BlackLevel : tag was not generated by DxO PL6.9
0xc61d WhiteLevel : 65535 65535 65535

R = 57837
G = 57837
B = 57837

as you can see DxO PL6.9 puts value in Linear DNG quite below 0xc61d WhiteLevel : 65535 65535 65535 and then expects other raw converters to think it is near clipping ?

Adobe ACR has no issues with original RAF, with linear DNG produced by Iridient and naturally with its own linear DNG… but of course with the linear DNG produced by DxO PL6.9 as it simply can’t get the act of working ( making them ) with DNG together

1 Like

the simple fix for stupid DxO coding is

exiftool -WhiteLevel=“57837 57837 57837” DSCF5499-DxO-fixed.dng

And then Adobe ACR does not produce any magenta with linear DNG from DxO PL6.9 as it now sees that there was a clipping

say hello to whoever was developing this piece of code in DxO… I wish to shake his/her hand

you need either (A) scale raw values properly or if not (B) put correct tags informing other software where the clipping is with your scaling

read what I wrote and simply ignore the rest of them folks , they have no clue :innocent: /how do I look with a nimb, not bad ? /

first do NOT… take a gun to a gun fight - that is rawdigger and exiftool

JoAnna - we all do love you truly for your dedication to DxO … seriously, jokes aside

Wonderfull !!! it works.
That do not explain why only with X-T5, but it’s a helpfull solution.

THANK you very much.

1 Like

please post a raw file from X-T4 or what else you have and let us do some (raw)digging - may be DxO does write proper data for other models ? we can’t say till we dissect actual files

Most killers use a .22… Silent deadly not a 12gage shotgun… :crazy_face:
Joke’s aside for me FRV is most of the time enough i don’t need to digg deep in rawfiles often.

In this case i did few things
1 use selective tone and advanged contrast to “recover” highlight by pulling 70 isch neg.
Then push shadow max up put the rawfile through the wringer and adjust with -2,48ecv to get sort of a image.
If it breaks it wil be then i think.
Then export as jpeg. Lineair DNG (all corrections) and rawDNG (optical module only.)
DxO didn’t show any purple but as my 4 image faststoneviewer showed the rawdng’s did.
Run the rawfile against the dxopl rawDNG showed a change in clipped channel percentage so the “pixelvalue” channel would be too.
(i didn’t look or care about sharpnes or any image quality i was looking for channel changing in balance. Which influences WB.)
The small test showed a demosiacing problem in channel balance.
Panasonic rw2 and s deephadows did also a redisch colorcast in night shots.
They recalibrated some things and it’s better.
(look for G9 and redglow on the forum)
Edit this thread

So @Merlinx63 assumption that DxO causes the purpleglow was correct.
The exact why ? Don’t know and frankly don’t have the toolbox and knowledge to pinpoint that. We have developers for that by DxO.
(edit: Because the reading of there own dng’s show no purple inside DxO PL o think they know how to solve it.)

@Merlinx63 you could ask a staff member to look at it upload your test files and create a ticket.

not where I am from … in any case - I provided a correct explanation with correct tools

1 Like

I have an old Fuji X-H1 camera , I shot a fully clipped raw, converted using DxO PL6.9 into linear DNG and used rawdigger to check - for that model DxO PL6.9 does scale data almost properly to clipping point ( as indicated by 0xc61d WhiteLevel : 65535 65535 65535 ) and Adobe ACR does GREY, not MAGENTA when “exposure” slider is pulled to the left

proper scaling for X-H1 =

So far all data points to the bug in DxO code for at least X-T5 model …

Simply because you have over-exposed more with the X-T5 than with the other cameras.

Once again, if you are seeing purple, it is down to Lightroom doing its thing with a completely blown area. It has nothing to do with PhotoLab, how it exports, all that techie blurb, etc.

That is not fixing the issue, it is a kludge that is changing the metadata to fool Lightroom into thinking that true white is not true white.

The original RAF file doesn’t contain a White Level tag.

The exported DNG file contains multiple White Level tags

[EXIF]          White Level                     : 65535 65535 65535
[XMP]           White Level                     : 27117
[XMP]           Adobe White Level               : 30726

65535 65535 65535 is the equivalent of 255 255 255 in RGB numbers (pure white)

By setting the White Level tag to 57837 57837 57837, you are actually setting it to 225 225 225, which is a very pale grey.

You can do exactly the same thing from within PhotoLab by simply lowering the top of the tone curve to that number…

Of course it does but, as I have just explained, all this does is change the metadata and not the image itself.

Much easier to just take the top of the tone curve in PhotoLab, thus adjusting the image and not just he metadata.

In fact, you don’t even need to go down to 225 225 225, just drop the top of the curve to 252 completely gets rid of the over-exposure warning.

No way! you provided a horrendous kludge that only changes metadata, not the image. Not all editors will read these tags or interpret them correctly.

please, do not post what you do not understand

people can make the call - the topic starter himself sees that what I wrote works… 2x2=4 no matter the image… as I noted your fan-girlish attitude towards DxO clouds your judgement… whitelevel tag is 101 for proper scaling of data when converting to linear DNG and accounting for what you put in whitelevel tag is 101 also …

PS: see down below direct reference to Adobe DNG standard that is disrespected in some quarters

it does indicate to a raw converter dealing with linear DNG where the clipping points are … and 50K-something as produced by DxO PL6.9 is NOT near any clipping for scaled 16bit uint data values, not even if some idiot decides to ignore values given in whitepoint tag because then that ignorant SOB needs to assume ~65535 as a clipping point , what else for 16 bit uint ?

Adobe does proper job by respecting whitepoint tag… DxO does shitty job by neither scaling properly ( for at least X-T5 model RAF to linear DNG ) nor indicating how it scaled by putting a correct whitepoint tag …

Adobe raw converters pay attention to 0xc61d WhiteLevel

it is in DNG specification, JoAnna - please for once TRY to educate yourself before posting ?

Let me try to help you = https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_0_0.pdf

see
WhiteLevel
Tag 50717 (C61D.H)

this is also from that same DNG specification… DxO just needs to follow the plain english here ( scale and tag as you told to do by senior komrades from Adobe ) and btw - write blacklevel tag too, it does not help to skip things