Processing the .NEF files from a Nikon Zf creates a weird tint to the highlights of the photographs.
Have tried all the processing:
- HQ
- Prime
- DeepPrime
- DeepPrime XD
Anyone else encountered this issue with your exports?
Looks like blown highlights to me.
1 Like
Sorry, I don’t understand your question. Could you explain it to me please?
How I use PureRAW is by right-clicking the RAW file in my Finder, and then just selecting Process with DeepPrime and let it work automatically. I didn’t toggle anything else.
Not sure if this helps provide more context.
…and there is not much you can do about it in PureRAW.
My apologies. I didn’t notice I was in the PureRAW section. Please forget this message.
upload original NEF or share elsewhere and post a link
might be a typical DxO code bug with raw data near clipping ( might be something else of course ) - but only with the raw in question people here will give you the proper answer
In PL 7.3 under Windows, the image opens without issue an does not show blown out / Clipped highlights.
With PureRaw 3.8.0 (current version is 3.10), I get the error message, that file is corrupt or has already been processed.
The file seems to be damaged.
same here – no problem in PL7.4.0 Build 151 Windows version [ I don’t have PureRaw ]
when treated with DxO Standard preset
the checked highlight warning shows overexposure
also the little “hand” indicates 255 for the blue channel
and so does the exported JPEG
Small amounts of pink cast, far less than on the first picture, can be seen on 20% quality (sic!) jpg export, but then the jpg compression artifacts are really huge (PL7.4/Win11). With minor WB, Saturation, Contrast, Lens sharpness and Optics corrections, using the camera rendering, the jpg export at 90% output quality looks to me almost the same, as embedded jpeg.
Can you provide us with the DOP file and exports settings?
It is fixed in 3.10,(on windows).
No .dop files from PureRAW…
OK, I forgot that it’s PureRAW, and as they say problem was fixed in PR3.10.
FYI, your first image was loaded into PL7.4/Win without problems, unlike reported corruption for PR3.8.
NEF in question shows the usual issue with DxO code both clipping unclipped raw data that is close to real clipping point and ( not mitigating this clipping error by ) scaling demosaicked data incorrectly vs white point tag it writes … DxO persists in this stupidity yet again … if you convert this NEF to linear DNG with DxO PL ( I am using v7.4 ) w/o no corrections preset + optics & NR only and convert the same NEF to linear DNG using Adobe tools (ACR/LR/Adobe DNG converter) you clearly see ( in that shiny piece of metal ) that DxO puts both green and blue channel to equal values as if both a clipped ( one is clearly NOT ) and neither scale data to white point tag written nor adjust white point tag well down to those values to redress the error to help another app further in pipeline … so opening this linear spit from DxO code in any normal converter with WB on top will results in magenta skies effect ( as green channel data was not allowed to be bigger than truly unclipped blue and DxO clipped blue making it equal to green, applying WB in another normal raw converter will boost RED and BLUE above GREEN channel = MAGENTA and w/o neither scaling to white point nor adjusting white point down that another normal software can’t engage any measures against that magenta skies effect - typically a normal raw converter will detect how close data is to clipping and adjust operations to prevent magenta skies effect, but DxO damages data and does not help by writing 65535 for all 3 channels as white point which is far far above where DxO code clips the data… so another normal raw converter thinks all is good we are long way from clipping and delivers magenta skies AS IT SHOULD in this situation) … Adobe correctly does not level both green and blue channel to equal values upon demosaick, so all is good there
DxO must either stop clipping unclipped data -or- at least either scale it (much closer) to white point or adjust white point down to it where DxO clips…
core issue is that DxO persists in clipping and loosing your, dear user, data … so as noted many times before… do not practice perfect ETTR with DxO or suffer you will
PS, I forgot to add - it is obvious
there is always no problem when thiefs are investigating their misdeeds themselves …
in reality there is a usual problem that DxO PL hides from unsuspecting users when the whole work is contained within its realm, but if your output is intended for other apps then things become unmasked …