in all fairness to DxO - it honestly displays its own true colors ( obviously magenta ) when round-tripping NEF → DxO PL → DNG → DxO PL
what do they say ? Medice, cura te ipsum (c)
obviously
stop talking rubbish – and please unhide your name if you want to be taken seriously
what do we see ? somebody don’t understand the problem, the source of the issue ( not that it is something new - there were a number of topics about this effect within last several month ) - and then instead of being filled with gratitude and appreciation when the matter was laid out and illustrated ( again, that was done several times before ) becomes upset and resorts to personal insults , that so obvious
and not the first time, I went back to the older magenta skies topic there he was as well with the same mantra “checked in old LR as well in PL6 – no problems” 
That’s interesting. I got the same result using ‘denoising and optical corrections only’ when exporting to DNG. However, when I used DNG export with all corrections applied, the result was good. It was OK also for TIFF exports with PCD ON or OFF. And I never got complains from PS people, maybe because I always used “full” export.
My corrections: small WB change (5580/+35), HSL saturation=-10, global Contrast=+20, DeepPRIME at defaults, Lens Softness=0.0, Vignette, CA at defaults, camera rendering, no distortion correction. No tone curve, smart lighting, or selective tone controls either. The corrections are not perfect, but look to me good enough. I’ll try the same without any corrections, if I find time, but maybe you have done it already.
that is exactly NOT how it shall be tested … as DxO simply masks the issue internally in this case ( granted chances are that they half-fixed the problem, before 7.4 it was well illustrated on synthetic DNG with a “greyscale” patches that DxO even inside can’t deal with unclipped data that is close the the clipping point - I might produce a synthetic DNG and check what the current situation with 7.4, I need to dig out my Matlab script and force myself back to the desk over the weekend — but they clearly demosaick unclipped data out for external processing in other raw converter, just like they did all the time before 7.4 … so my bet is that internally it is still the same bug )
PS: “illustrated” above was not that DxO PL was showing the magenta tint , no… you fill DNG with uniform “white” background ( say put all sensels @ clipping ) then you put greyscale in it gradually approaching clipping in raw channels, and then you bring it into raw converter… whereas ACR/LR will show you all patches clearly over the background ( so it does not clip) , but DxO PL can’t do this for patches close to clipping they are as clipped as the background - no matter what you do in UI controls DxO PL will not discern those patches from background… that was the test - plain and simple … magenta tint is just how stuff manifests itself if you use DxO output in other raw converters (or as obviously illustrated in DxO PL itself - may be that will move the stone, not that no other software is involved except the PhotoLab itself … somebody file them a ticket about this with a screenshot … may be they will not resort to hide the tint, but fix demosaick ? ), the core issue is that DxO code destroys data ( and I can’t think about good reason for them to do this on purpose )
Yes, but this is exactly the way it should be used, at least for my workflow.
However, agree, the problem is obvious.
Edit:
Tried 4 combinations of
Original NEF without any corrections vs DeepPRIME (defaults) only.
Export DNG “full” (all corrections) vs “partial” (denoising and optical only).
“Pinky” DNGs:
DPL7.4: Partial/DP only.
Win11 ‘Photo’ app: None.
FRV (2.0.7): Both partial.
your workflow does not matter for OP and for the fact that there is a bug in DxP PL and in DxO pOOrRaw too … this topic is not about your workflow … no disrepect meant - just polemic
PS: and in your workflow you simply do not notice the bug that the data is gone and destroyed by DxO code - now that of course might not matter for you, for as long as you do not see pinky pink w/o stepping outside of PL or w/o round-tripping ( which - round-tripping - makes more sense with just to DNG + NR/optical corrections [ and there we see stinky pinky ] only vs otherwise all corrections included (DNG or TIFF for example), but of course otherwise can have its purpose too - for example if you want to double down on some corrections where one go is not enough in PL and whatever sliders were at the limit :-), so you bring stuff back and repeat that correction again … quite exotic example, of course )
Neither does DPL 
I was just worried if I can get hit by the problem and it seems it’s not the case. Over.
as promised = https://app.box.com/s/ige13nac8hlp1hyj61sc01sf3cx0me2t
this is a raw file with a whopping ( obviously ! ) 1536-steps greyscale wedge
top-left corner a patch @ black level
bottom-right corner a patch @ white level
background @ white level
a normal raw converter like Adobe ACR/LR will display 1535 distinct patches ( whitelevel on whitelevel naturally blends to background always, so bottom-right corner patch is invisible in principle )… now check what DxO demosaick will do , that is how many patches its famed demosaick / will assign blame to it for now / will be able to get ( start with no corrections and WB = as shot )
how much data is lost ? close to 1/2 stop of data before clipping rendered into oblivion… A way to go, DxO… 
illustrating that ACR does not clip anything that is present in raw ( 1535 patches delivered )
neither does C1
rawdigger says it is all there
Thank you for this illustrated demonstration.
Do you know why FRV (v2.0.7) also clips (but much less than DPL)?
I assume you have also tried it with an uncompressed version. Formally DPL does not support compressed or edited files generated by Adobe DNG Converter – just not to be possibly diverted by another bug.
Looks like an obvious case for escalation to support.
@slgcjt – does your problem appear also with TIFF exports (if TIFFs are acceptable for your workflow)?
you mean why FRV does not show last 7 patches ( one in invisible, so 6 → which is ~1/48th of a stop to clipping - see RD screenshot that shows first clipped patch vs whitepoint )
I do not know, but you can ask the authors ( make sure to give the link to the raw file ! ) - I bet Alex will answer you in 24-48 hours given the weekend and time difference vs Russia
it was escalated many times - that “magenta skies” is direct result of this matter … you can’t fix “magenta skies” effect in a genuine maNNer w/o fixing the underlying bug … may be instead of fixing the matter in general DxO was/is ( if at all ? ) patching the code for camera model by camera model [ case by case ] ( like somebody complained about a specific camera and DxO fixed the code only for that camera model ) … may be their code is so bad that it works that way [ can only be fixed for each camera model individually instead of just in one place that takes care for all cameras ] and they are too “busy” to go through the code for each and every camera model
This was tested in house on uncompressed, lossless compression was added for convenience ( faster download for curious observers, as lossless compresed is 10+ times smaller )
As for edited files - it is not edited , it simply has image data ( sensel’s DN ) replaced in situ
and PS : not only 1/2 stops of data before clipping will be annihilated by DxO code… certain ill effects with how DxO applies tone curves will start happening a bit more than 2/3 of a stop before clipping ( tone curve applied to not yet clipped data looks like some death throes across last 1/6+ [ 2/3+ - 1/2 ] of a stop before heart monitor flat lines )
turns out FRV does not clip, here we go - I manipulated with some FRV settings to force it to display missing patches, so no clipping in FRV either
PS: in FRV preferences I changed “Use Monochrome mode for Bayer images” to “Always”, a bit of a hack - but shows that FRV does not clip
Today I found the same problem with nefs from Nikon Zf 
welcome to the club
@Wlodek TIFF exports don’t work for me because of the highlight and shadow recovery as compared to DNG