of course, you don’t
a perfect workaround not chaning topic starter’s workflow ( to use linear DNG with only optics corrections and NR applied ) was already given - correct the relevant white point tag in linear DNG so that ACR/LR will see that there is a clipping in raw and engage necessary corrections when brightness is pulled back … that guarantees that no other - possibly unwanted - corrections are passed in linear DNG file to ACR/LR
Are you a joking AI ?
Anyway you are finally funny.
Maybe should I launch you on this :
Is it faster to create a preset and apply it on all bugged images than changing software, modifying metadatas and so on ?
I think your next post will be funny too.
We have past photolab area and are in psycho area now.
there is no material difference for “dynamic” (whatever it means) and I did not scale to 57837 - DxO did, I suggested to adjust the relevant white point tag to conform to DNG standard as it is just easier to fix the tag with exiftool ( for example ) , rescaling data in already generated linear DNG will require some coding … plus that was not you, that was DNG standard ( but broken clock does show correct time twice a day )
No but DNG reaches this way (scaling to 65565 with curve tool) the right white point value for dodobe sofware (which created the format, I know that - you know I know that ?).
Your deductive circuitry is not really fine tuned.
Only your memory circuitry works fine ?
Adobe DNG standard ( not you ) requires that scaling and relevant white point tag shall match (scaling follows the tag) … white point can be anything for as long as the scaling follows … that is DNG standard does not actually mandate the relevant white point tag in for linear DNG to be = 65535
Call it as you want (my english lacks).
But doing this (scaling to 65565 with curve tool), adobe translate white burned as white and not purple. So “the up limit” coincide.
And, as I told, maybe colors are shifted ? (Don’t jump on this like a lion !).
Depends of the bug.
And, anyway, thanks for all your explanations which are right (this does not desserve a gorilla 
)
I still don’t know the solution. Only that dxo states it is on their side.
George
in addition – NOT only DxO ( as of Windows 7.0.1 ) scales & tags (with “0xc61d WhiteLevel : 65535 65535 65535” ) linear DNG improperly - it also clips raw data where there is no clipping in raw
raw file example = https://www.dpreview.com/sample-galleries/2421645301/fujifilm-x-t5-production-sample-gallery-dpreview-tv/3536605057
animated gif ( screenshot from RawDigger ) illustrates how 2 channels are NOT clipped in raw but yet DxO PL upon conversion DOES clip ALL 3 ( where 2 are NOT clipped ) channels ( that is again on top of improper scaling / tagging )
pay attention to selection area in RawDigger
URL to full size = https://postimg.cc/7bX9N9GR
this NOT specific to XT-5 , this is a bug in DxO code in general
DxO PL7.0.1 / Windows ( export to disk as DNG with “Denoise & Optical Corrections only” after applying DxO’s “No Correction” preset )
Adobe DNG Converter v16.0.0.1677 - export to linear DNG
I only see an out of camera jpeg with a certain film simulation. No raw.
That might be possible depending to the color space to which it’s converted and the used rendering intent.
That’s a different dng.
George
look harder… hint ( press something like CTRL+F to seach in browser’s window and type raw )
George it is long established that you totally lack attention to the details ( any details ) … did you read : export to disk as DNG with “Denoise & Optical Corrections only” after applying DxO’s “No Correction” preset ? what “color space”, George ?
yes, exactly, George - Adobe’s linear DNG is an example of a properly generated one … that was the whole point to compare different DNGs, George, wasn’t it ?
Thanks for pointing me to the raw. Really nice of you.
You start growing up.
Looking at your rawdigger examples I see that DXO has a min of 0,0,0 and ADOBE a min 3063,3714,2996.
For the max. DXO 5944,5944,5944 and Adobe 6535,6535,6535.
Overexposure with DxO is 0%, with Adobe 0%,8.8%,2.6%.
Underexposure with DxO is 0.1%,0.0%,0.2%, with Adobe 0%.
I don’t know if what I say is stupid but it looks like DxO is blackpoint based and Adobe white point based.
Ok, start shouting.
George
George, ( A ) DxO PL code does not write 16bit uint digital numbers ( values in raw channels ) matching its own “0xc61d WhiteLevel tag when it creates linear DNG ( or does not write “0xc61d WhiteLevel tag with values to match how 16bit uint digital numbers were written ) and ( B ) DxO PL6 code clips data upon conversion to linear DNG where data was not clipped in the original raw - both for export to disk as DNG with “Denoise & Optical Corrections only” after applying DxO’s “No Correction” preset , it is a bug ( both A and B ), it needs to be fixed
BlackLevel tag ( there are several BlackLevel related tags used for calculations ) are used further when linear DNG is opened and processed in raw converter and then it does not matter if black level was zero or not as written in linear DNG … because for ( B ) what was not clipped in original raw was clipped by DxO and for ( A ) rescaling upon black level subtraction ( zero or non zero - does not matter ) when linear DNG is ingested will be wrong - welcome to Magenta Skies effect for example when you pull down brightness in a converter like ACR/LR that expects the linear DNG to be properly created ( and it is not )
From https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_0_0.pdf
WhiteLevel
Tag 50717 (C61D.H)
Type SHORT or LONG
Count SamplesPerPixel
Value See below
Default 2BitsPerSample - 1
Usage Raw IFD
Description
This tag specifies the fully saturated encoding level for the raw sample values. Saturation is caused either by
the sensor itself becoming highly non-linear in response, or by the camera’s analog to digital converter
clipping.
The default value for this tag is 2BitsPerSample - 1 for unsigned integer images, and 1.0 for floating point images
Exactly what is in the dng from DxO. And it is 16 bit.
Changing this tag to a lower value might have given a better result, but doesn’t explain anything yet.
George
@noname
Again no answer on this question.
White level in the dng specs is specified as the max value a pixel can have: 255 for 8 bit depth, 65535 for 16 bit depth, and for floating point 1.
What makes this image so special that the white level should be different from what is specified in the DNG specs as default???
George
Hello all,
Good news, in PureRaw 3.7.0 the issue is fixed. No purple hightlight.
BAD news
(A) not fixed in general - only may be for this camera model … this raw, for example, continues to exhibit magenta skies
https://img.photographyblog.com/reviews/leica_tl2/sample_images/leica_tl2_06.dng
and
(B) as usual DxO continues to lose unclipped details upon conversion to DNG ( only NR/Optics correction applied )
illustration - first frame is ACR with original RAF, second frame is ACR with DNG after DxO PL7
original GIF = PL7 losing data near clipping — Postimages
so USERS be warned = DO NOT ETTR if you intend to use DxO to convert to linear DNG and process in other converters… DO NOT
