again, your knowledge is very appreciated.
But this last sentence is maybe not necessary, don’t you think ?
@noname
This last animated gif leads to a question :
Why do you post on forums ?
To feel better ? to prove yourself you have value ?
This is sad because it does not need this attitude.
Or maybe you really are an AI bot test trying to fool people ?
2 Likes
Need to call a blade runner to check this.
if you did not notice - I explained where exactly the bug is to the topic starter … so here is why … also along the way I tried to explain to you, george, etc where to find the relevant information using relevant tools and how things work ( shall work ) actually in raw converters and with linear DNGs … so ignore the gif - digest the knowledge …
@noname
I don’t have to digest what you think is so big knowledge that it needs time to digest.
I know the principles, even if when writting english my brain is very absorbed to search words in my not native langage (you’ll notice I’m probably the one who needs to correct its posts the most on this forum) and makes me loose some base in route.
Anyway what I told was it is better to scale from 0 to 65535 than 0 to 57837 as you did.
And this is still the case (Don’t worry, this does not need to be digested).
And I’m not talking about bug (in case your blindness strikes again).
But about trying to fix this (find a workaround) fast to not be stopped in production.
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.
1 Like
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