I am not - others are … did you read John-M posting ?
let me repeat it for you again
You’ve convinced me and some others here that we are dealing with a problem in the demosaicing pipeline - can we just focus?
The camera name change alone – I didn’t find any other changes in the edited file per EXIF Tool – apparently triggered a different demosaicing pipeline. The edited camera name had to be pointing somewhere else and the set or subset of parameters used in constructing the specific DxO camera / lens module seems a likely candidate to me. Why keep two sets of books? In that scenario the Nikon Z Df camera name could be pointing to a null or faulty source for its demosaicing parameters. This armchair conjecture need not impinge on your emphasis that there is a more fundamental and systemic problem.
Maybe the problem is with the way LibRaw is used. See General Notes on API | LibRaw
"
Automatic maximum search/brightness adjustment
Many camera formats really use less data range, than possible by format nature (bit count). If data maximum estimated incorrectly (too low) this may resuls in colored highlights (‘pink clouds’) because of data cut at wrong level.
To prevent this, LibRaw uses real data maximum from current file if this maximum is larger than format maximum multiplied by imdata.params.adjust_maximum_thr value (default is 0.75).
To turn off this feature (and repeat dcraw.c pink clouds) set imdata.params.adjust_maximum_thr to 0.0
"
Also
Pink Clouds with LibRaw 0.20.0 | LibRaw
Pink/purple color cast on Sony A7III ARW file? | LibRaw
etc. Just search www.libraw.org for pink or magenta.
Note that the current official version of LibRaw (0.21.2) does not yet support Zf, nor Nikon High Efficiency compression modes (seen in another pinky Zf topic),
so DxO (like CO) uses a specially crafted version. But maybe the current problem has roots somewhere else…
note that RawDigger which is a paid app created and sold by the authors of LibRaw has no issues like DxO … so one can assume that DxO is either NOT using LibRaw or they don’t know how to use it or they are not using it for this purpose but for something else, etc … note that Adobe DNG converter creates a specific tag in DNG file for an app to use ( and DxO ignores this tag - which might be OK if otherwise they know how to decipher white level , which seems to be not the case for Zf ) … and DxO knows about this tag as it also creates it when the output from DxO is a linear DNG… but left hand might not know what right hand is doing in their codebase
So why there is a libraw license in PhotoLab installation?
do full quotes = full line is “so one can assume that DxO is either NOT using LibRaw or they don’t know how to use it or they are not using it for this purpose but for something else, etc”
whatever they do the end result is they do not do it correctly hence we have a bug
to prevent magenta tint/magenta skies w/ linear DNG output from DxO that will be used elsewhere one simply can scale raw-demosaicked data and/or adjust white level tag for created linear DNG ( this is not fixing the bug, this is preventing further additional contamination on top of the damage with destroyed data ) , what is outrageous that not only DxO clips and calculates white level incorrectly they dare to scale the data well below white level DNG tag that they themselves write in DNG output so other well behaved apps left to produce that magenta tint effect … it is as if the coder over there behind that part has no clue what pronoun-self is doing… left hand calculates clipping point ( incorrectly ), right leg clips the data below whatever white level calculated , right hand then writes white level DNG tag clearly different from what left hand did… may be obvious staff turnover after certain corporate events in the past resulted in this ?
another point … LibRaw ( library and apps like RawDigger ) do not support Nikon HE/HE* formats and DxO does - correct me if I am wrong… so clearly in this case DxO got Nikon SDK from Nikon, no ? again correct me if I am wrong here … so may be DxO is not using anything from LibRaw to deal with NEF files even for formats that are supported by public or commercial versions of the LibRaw code … that paid apps from LibRaw authors do not support still Nikon HE/HE* formats says that they do not have anything even for their commercial customers ( for LibRaw ) for that format, not only in public LibRaw codebase… $0.02 - pure speculation on my part
but situation with clipping of raw data by DxO code is not unique to Nikon models … it is widespread across camera from different manufacturers… even in cases when raw file itself clearly tells what is the white level in the original raw format through a publicly known tag written by camera’s firmware… so what does this tell us ? speculation - may be some time ago somebody did this on purpose ( that clipping ) , since left / died / was terminated and that piece of code still lives unmolested and unaudited ( or may be preserved on purpose for the sanctity of parametric edits already committed by unsuspecting user base - might be possible that DxO is fully aware about the matter but just like with once done unfortunate choice of UI interface dev library/framework they got themselves cornered now by a choice once made time ago )
Long ago Nikon SDK was mainly for remote camera control, without any RAW reading or demosaicking functions. Nikon always kept their secrets well hidden, though some were reverse-engineered. Maybe it can sell some other libraries, but all that is pure speculation. I think enough was done here for DxO to have some valid hints and I wouldn’t expect DxO to reveal any details.
I am not referring to that particular SDK - there shall be some / call it SDK or codec or whatever / that deals with access to decode and decompress for paying customers … Nikon might not share all of the info, but they might sell / license enough for 3rd party to read essentials… again pure speculation and $0.01 even
I did get a response to my ticket. They apparently don’t care enough to click on the link to this thread and asked me to resubmit a ticket with my description of the problem. Well, I won’t do that so if anyone else is in the mood, you’re welcome.
so I am doing some further experiments with first NEF raw files provided by OP … let us do the full set of tests to make sure that DxO code indeed converts DNG exactly as it converts NEF in terms of image frame data …
NEF → Adobe DNG Converter → DNG
then
NEF → DxO PL7.4 (default RAW preset) → TIFF(NEF)
DNG → DxO PL7.4 (default RAW preset) → TIFF(DNG)
MatLab >> T1 = imread(‘z:\_PAP2059DNG-DXO-FULL.tif’); T2 = imread(‘z:\_PAP2059NEF-DXO-FULL.tif’); isequal(T1,T2)
ans =
logical
1
NEF → DxO PL7.4 (default RAW preset) → linear DNG (all corrections applied)
DNG → DxO PL7.4 (default RAW preset) → linear DNG (all corrections applied)
MatLab >> R1 = rawread(‘z:\_PAP2059DNG-DXO-FULL.DNG’); R2 = rawread(‘z:\_PAP2059NEF-DXO-FULL.DNG’); isequal(R1,R2)
ans =
logical
1
NEF → DxO PL7.4 (default RAW preset) → linear DNG (Denoise and Optical Corrections only)
DNG → DxO PL7.4 (default RAW preset) → linear DNG (Denoise and Optical Corrections only)
MatLab >> R1 = rawread(‘z:\_PAP2059DNG-DXO-NROC.DNG’); R2 = rawread(‘z:\_PAP2059NEF-DXO-NROC.DNG’); isequal(R1,R2)
ans =
logical
1
so thankfully DxO code works as expected… DNG from NEF → same output
so we can surely just change the sensel data for our purposes to produce synthetic raw file
promised experiment… we inject 81 sensels ( 9x9 ) set to Adobe’s calculated clipping value in the image frame and , oh magic, DxO starts to work as it should ( it still clips, but at least leaves the skin which is well below where it clips alone )
hRAW = Tiff( ‘z:\_PAP2059.DNG’ , ‘r+’ ); setSubDirectory( hRAW, getTag( hRAW, ‘SubIFD’ ) ); mDN = hRAW.read(); mDN( 40:48 , 40:48 ) = 15892; hRAW.write( mDN ); close( hRAW );
that simple
proof (raw file) = https://app.box.com/s/0x5d48rqqhj8l47prz8u8ctyx0ab13g2
second promised experiment, this time we leave max DN in image frame as is, but instead we will scale the rest of the image DNs down ( sans the 9x9 sensels spot where we put back the old max DN value )
hRAW = Tiff( ‘z:\_PAP2059.DNG’ , ‘r+’ ); setSubDirectory( hRAW, getTag( hRAW, ‘SubIFD’ ) ); mDN = hRAW.read(); mDN = uint16( ( mDN - 1008 ) / 1.5 ) + 1008; mDN(40:48,40:48) = 12400; hRAW.write( mDN ); close( hRAW );
and of course DxO again leaves skin alone as now it lays well below both how DxO incorrectly calculates white level and below where DxO starts to destroy data
proof (raw file) = https://app.box.com/s/rpodvlmc5pkxlw4687zmagqmmb059qsv
or simply afraid to face the music
Yes, they seem overwhelmed by the multitude of problems and unable to solve them …
After “lost in space”, “lost in time”, now “lost in code” by DxO …
1 Like
I agree support has never been very good and all the mounting problems I think are over whelming them. All to often it was DXO staff here who had to get problems resolved after support had denied there was anything wrong and without them being here now…!
I keep being asked for the same information to do with the Internal Error bug which never sounds hopeful not least trying to get me to close my ticket on it recently. Highlight clipping as a reported problem has been around since PL was released and I expect it was there before. The exact causes may well have been covered here in depth for the first time rather than just regular complaints of it. But its a long standing issue that’s been ignored by DXO.
Here we touch the core of why I think lot of stay with photolab.
This is not because of it’s interface (sluggish even on top end computers).
This is not because of its functions (it lacks a lot of basic functions and existing ones are very very … basic).
This because people think they have a good, if not the best, demosaicer which allow them to get the best from their camera and lenses (even if colors are really wrong and need lot of work).
But clipping raw and loosing datas ruins a good part of this !
demosaick in nothing special … may be you mean NR (DP/DPXD), but now it is already approached by Adobe and I bet, next year, will be approached by C1 … and optical corrections - that again for most purposes and for wider auditory are simply covered by manufacturer’s own optics correction embedded in raw files + Adobe/C1 do make their own profiles… there is no point to argue that for mass consumption those do work… what else ? refuge for people not willing to pay subscription ?
Yes my words are often not precise enough when I speak english.
But as they say denoising is done at raw level, this is what I meant. (I was there including, not very accurately I know, everything that happens at the raw level in the demosaicing term - as well as optical corrections which ocur at raw level too).