Sorry my english lacks (and dictionnaries does not help here) : what is a “donor” raw ?
take it literally → for the purpose of this thread the donor raw(s) was/were the raw(s) that OP shared for example , we modify the image area data ( sensels’ DNs ) to test what we need to test
Many users believe that DeepPrime is only about noise reduction, this is a mistaken believe. Deep Prime uses also a new demosaicing platform in addition. Therefore it makes sense to use it as default.
Ah, ok.
This was not my request. But thanks for the links anyway.
what was your request then ? you want to test something for a specific camera model, etc - you take the donor raw that suits the needed conditions like a nominal ISO, etc and proceed as indicated above … do you want to test something for a different camera model or shooting conditions ? you make another donor raw and so on … no, I do not have a magic app where anybody can drag and drop files, I do it manually in Matlab - my last “IT” job was in 1998, so I do not write a code for a living for a long while
and it has simple bugs producing maze artefacts ( the NR tool for DP/DPXD does not offer users any options to control demazing, unlike prev. demosaicks ) for certain camera models where DxO fails to control it internally - apparently “bespoke” camera testing ALSO does not include testing for green channels disbalance in various conditions … if you do not test to control / eliminate maze behind the scenes then make available an option in tool’s UI for a user to control it in DP/DPXD variants
most recent example = Strange RAW file import
What’s in a name? I did not read John-M’s post as indicating that he believed that the specific problem is with the post-demosaicing application of a faulty camera profile. Just that there is a problem. My take is that a change in the camera name in metadata is apparently enough to trigger a change in the demosaicing algorithm itself.
let us take a look, shall we ?
it is in black and white there = he says, QUOTE : “With the entirely reasonable suggestion that” referring to the following heresy
and this after all what was written in this topic above …
GRRRRRRRRR… (c)
Still looking. What’s in a name? So you don’t think that a null or faulty camera name / module is enough to trigger a change in the specific demosaicing algorithim?
did you manage to read what camera profile is ? do you need any assistance in finding the explanation in the posting that is just below the posting in question ?
also did you manage to read the original comment way above in this thread
all that was covered and explained … one just needs to pay attention
PROFILES → NO
SPECIFIC PROCESSING ( different for camera models, etc ) <= DEMOSAICK STAGE → YES
Changing the name in the RAW file forces the converter to use another module for the demosaicing process. We’re not talking about camera profiles.
George
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.