“magenta skies” effect when brightness pulled ( in ACR/LR ) due to the improper data scaling in linear DNG output ( we will use that linear DNG from DxO PL6 in ACR/LR to test ) is not only limited btw to X-T5 in DxO PL
@ Cecile-C - why does DxO PL6 NOT scale the data in linear DNGs up to the value of 0xc61d WhiteLevel tag you write ?
PS: Adobe DNG converter scales to 65535 and writes tag 0xc61d WhiteLevel = 65535 per channel… yet DxO PL6.9 writes the tag 0xc61d WhiteLevel 65535 per channel, but scales still well below what tag mandates ( to 62085 per channel )
PS2 : as usual the matter is with the export to linear DNG with only optics correction and NR applied, as the other type of DNG export will bake in white balance ( for example )
If DNG which noname checked comes for photolab (and it should be the case), Photolab did it when converting RAW to DNG : it produced datas from 0 to 62085 instead of 0 to 65535 as tags it (photolab) wrote in this DNG implies.
(unless I don’t understand your question and you’re suggesting it comes from the software used to read those datas (rawdigger) that is wrong. I don’t know what to think about my understanding of English after some last discussions on the forum. But I don’t think this is what you meant).
photolab RAW to DNG conversion algorythm.
Unless there is a bug in leica TL2 raw which distorts some information for conversion algorythm (any possibility has to be consider, but this is the less probable cause).
All this supposing there are burned part in the image checked (if not, 62085 can be right).
I open that dng in pl and I see no color cast. So either there is no color cast in the dng or it is not showing the dng but an embedded jpg. I downloaded a dng viewer and it shows a color cast.
So a next question will be what is pl showing when opening a dng.
It seems that it does not happen in photolab (so photolab can interpret what it wrote) but it happens when opened in adobe software (exported with pureRAW for example).
DNG being used by photolab for compatibility with other softwares (for exporting a kind of RAW with optical corrections applied) , it should use adobe conventions since they created this format (container).
So it seems DxO team does not do right basic verifications (testing a full color/luma palette image - in range from underexposed to overexposed - and checking import in adobe software) when they create profiles (which will be used with pureraw too).
Or something has been broken at some time (updates ?).
Which leads to a question :
What will happen to users which have saved DNG with those “bugged” profiles - or anything else - for photolab use (not adobe use), and which apparently works fine in photolab, when this “bug” will be fixed ?
just to clarify the original post = as usual the matter is with the export to linear DNG with only optics correction and NR applied, as the other type of DNG export will bake in white balance ( for example )
Anyways, clipped highlights can produce all sorts of unexpected results, even when tricks like Leica’s are used to avoid clipping alarms…remins me of Dieselgate
Nevertheless, Lightroom shows no pink skies.
it does when you export to linear DNG with optics correction + NR only , open that linear DNG in ACR/LR and pull “exposure” slider down … convert to linear DNG using Adobe DNG correction too and compare scaling that Adobe does vs scaling that DxO PL6 does… it is all about that
rawdigger can be set to show ( or not ) clipping based on what you tell him to show in preferences - visit preference dialog and see what they are … And we are talking about DNG Specifications ( whitepoint tag vs how the data in linear DNG is scaled )
again - export to linear DNG with optics correction + NR only … what you set in DxO PL6 in tone curve does not matter, it is neither optics correction no NR… right ?
no - with proper scaling respecting whitepoint tag clipped highlights produce expected results … fix the relevant white point tag in linear DNG after DxO PL6 and ACR/LR will work beautifully with clipped highlights, because then it will see they they were indeed clipped and pull will not produce any magenta skies … scale far enough from whitepoint and ACR/LR rightfully will not consider that there was any clipping
because of your settings in rawdigger … rawdigger does not have any set standard how to show the clipping - it is a user’s call what they tell rawdigger to show - see the preference dialog…
If the export from PL is optical corrections and nr only, what about gamma correction? It makes the image darker but doesn’t change the extremes, 0 and 255.
I downloaded an app “raw image viewer”, it only shows the raw image, no editing posible. It shows the same image as in LR, well I think.
So, even changing the colour space makes a difference.
Next, the only thing I change is to reduce the top of the Tone Curve from 255 to 252 and export to DNG with all corrections. In other words, with just the tone curve added in…
George - this “with all corrections applied” is not the subject of this discussion … this is about export to linear DNG with only optics correction and NR applied
JoAnna - this is about export to linear DNG with only optics correction and NR applied - if you found ONE MORE error in DxO PL6 where DxO does different export ( in terms generating demosaicked data ) based on WGS vs Legacy then my sincere congratulations, because that shall not be affecting that type of export at all !!! color transform happens ALWAYS after demosaicking and [ optics corrections + NR (in DxO situation) ] before demosaicking
BUT you shall NOT be using DxO PL6 to check what is happening … the whole point is for DxO PL6 to do a proper export so that the linear DNG will be used in a 3rd party raw converter w/o any issues …
because, Joanna, exporting linear DNG with corrections applied means that DxO will bake in also things like WB = white balance ( and not just your beloved tone curve ) … and “we” ( not you, but some subset of people with different needs ) want linear DNG with only optics correction and NR applied that can be properly used by other raw converters… that means for example not having extra stuff like WB to be baked in demosaicked data
no matter how many workarounds are suggested - DxO needs to fix the bug … they recognized the issue w/ X-T5 model - they did… but that issue exists for other models ( even on a smaller scale, but it is ) - what is the logic not to scale the clipping to the relevant whitepoint tag values ? either there is a reason to leave a big gap OR it is a bug … I can’t see any reason , unless as it was established DxO PL has another bug where upon bringing a DNG like this in itself ( round trip ) if clips what is actually not clipped in raw and hence catch 22 - they try to leave that gap to avoid clipping if that linear DNG is fed back into DxO PL6 - but then give users an option to indicate whether this linear DNG is intended for DxO PL6 again ( and so leave that gap ) -or- for normal raw converters ( scale to whitepoint tag values )
JoAnna - if you are talking about RawDigger indicating overexposure in frame or not then as I noted more than once in this topic above it all depends on how your setup that indication in RawDigger preferences… so this is really a convenience feature in rawdigger and it depends on how your tell rawdigger to do this… so screenshot of RawDigger screen means nothing w/o taking into consideration how did you instruct RawDigger to find the overexposure to indicate
… the whole point is for DxO PL6 to do a proper export so that the linear DNG will be used in a 3rd party raw converter w/o any issues …