[quote=“platypus, post:221, topic:37138”]
The glow and the burnt highlights can’t be corrected in PhotoLab, while other apps show a perfectly lit portrait of the child. [/quote]
I’m not convinced of that, but when I tried to open the file in DXO I couldn’t. Not sure why, it does not recognize the format. All I know that every image that I was able to correct in Adobe Camera RAW / Lr also was corrected in DXO and I had no problems before Noname started obsessing about something I’m not even convinced its really a problem. So far all other RAW files uploaded to this thread could easily be processed in DXO PhotoLab and details recovered from seemingly blown highlights. Short of actually no recorded data in the highlights I’ve seen different type of image processing between DXO and other brands, but not to the point of not able to process, just different results. As to be expected. Same is with color. That is the nature of raw processors. Sounds like witch hunt to me.
I like posts when somebody acknowledge that “not sure what all those numbers are supposed to represent” but nevertheless feels self qualified to question what is being illustrated with them …
tentative theory is : DxO code first tentatively find a correct clipping point, but then next step in DxO code is to scan the image frame with ~1/2 stops down from that first assumed ( correct ) clipping point AND IF it then finds a spot (enough RG1G2B sensels ) there that looks like a possible clipping ( that is what I do by tricking it ) it backs down ( discards the originally found correct clipping point ) and decides that this is the clipping point to work with and from there it all goes wrong
R = Tiff(‘z:\RAW01384.DNG’,‘r+’); setSubDirectory(R,getTag(R,‘SubIFD’));M = R.read(); M(2500:2510, 7300:7310) = 11681R.write(M);close(R);
11681 lies below scanning threshold and DxO code leaves the originally found ( correct ) clipping point as is
R = Tiff(‘z:\RAW01384.DNG’,‘r+’); setSubDirectory(R,getTag(R,‘SubIFD’));M = R.read(); M(2500:2510, 7300:7310) = 11682;R.write(M);close(R);
11682 hits the threshold and DxO assumes that it is the proper clipping point not the one detected earlier in it is pipeline → mess
and the mess continues from 11682 onwards
so if you fully clip when shooting - good, if you happen not to clip but come closer you trick DxO code into wrong assumptions … if you stay below ~1/2 stops from clipping - also good
this is tentative theory of how DxO works … obviously between metadata tags and actual DNs in the image frame the question still is how DxO find the first tentative clipping point before it proceeds to validate / invalidate it
11681 or 11682 are DNs w/o black point (512) subtracted
remember the original Zf NEF ? - there were NO clipped senses, but the OP happen to expose above ~1/2 stop ( to real clipping ) threshold …
so DxO code promptly invalidated the correct clipping point and assumed that some max DNs in the frame are actually the clipping point then ( obviously incorrectly ) - AND as DxO still has a bug of clipping unclipped data - DxO code obliterated skin on kid’s face… AND as DxO still has a bug of incorrectly scaling linear DNG output ( DOCO ) it was topped with magenta skies effect…
PS: this does not constitute the Zf processing code has NO other Zf specific specifics …
Not from my side. I got the file and inspected it with RawDigger, which showed no signs of burnt highlights. Nevertheless, DPL showed the sweaty glow we see in the first post and no preset fixed it completely. If the image looks okay on your computer, there might be another difference between Win and Mac versions and then again maybe not.
The important part imo is to have reported the issue and I suppose that DxO will try to find the cause and fix it. We’ll see.
I tried to open it in Adobe Camera Raw and it reads the file with no problem and no problem recovering highlights detail. For some reason DXO PhotoLab did not recognize the RAW file and won’t open it for editing. Not sure why. But in Adobe Camera RAW all details are easily recovered and no visible problems. I know from previous test that if I can recover it in Adobe appls, DXO will also recover it, unless there is loss of recorded details in the RAW file itself. However the way highlights are recovered sometimes looks different in different RAW processing applications. This is because different apps treats RAW data differently. Weather one likes the results or not or one can massage the image to his or her liking is a matter of preference I would say, not so much performance.
I’ve worked on many thousands of photos in DXO PhotoLab and I don’t think I’ve encountered blown highlight details that was a problem to tame with few sliders, unless, again there was no data in the RAW file to begin with. To my knowlage and experiance DXO performs similar as expected of all RAW processing apps.
If there is any bugs, I can’t say, but for few generations of DXO PhotoLab I have not encountered a problem I feel is a matter of buggy software when it comes to highlights recovery. That is just my experience.
How did you check in this case this was because real raw overexposition ?
What is your method to be sure that Photolab always recover if no raw data saturation ?
Simply by looking at the results. Unless there was specular highlights or inadequately exposed photo, I expected the kind of results I would get. I didn’t go beyond of double checking the R,G,B, values if that is what you mean, but to me if it looks good, there is nothing more to it. I didn’t go into any kind of forensic analysis because I see no need for it.
Here is one example of original and recovered highlights by DXO, with the exception of the sun of course which should be under category of specular highlights in a photo.
No, I worked with wide variety of cameras, and short of some older Canon sensors from about a decade ago, I generally found that most modern raw processing apps, do similarly good job. Same is for recovering shadow details, usually noisy but with modern AI noise reduction and demoseicing its less of a problem.
I did find that there are differences between say, Lightroom, Capture One and DXO in the way sliders works to recover highlights, but I find DXO offering quite a few options to adjust tonality so it just requires different approach.
There are examples where Capture One and Lightroom has a gentler highlight roll off using tonal sliders for Highlights, lights, mid tones and shadows. DXO equivalent of those sliders is a bit more harsh so transitions between specular highlights or completely blown out sky are rest of the image can be a bit harsh. But generally it requires use of few more sliders to make it similar to Capture One and Lightroom. But I find this to not be a common problem, only sometimes, depending on the image.
If there are bug, report it to DXO. When I look at your posts , I don’t see bug report, I see unhealthy obsession and desporate need to prove something I don’t see as a problem, but if you insists its a bug, fine. Mark it as such. Don’t try to wave around with your inflated ego that others should accept your obsession. Go take some nice photos instead. You might feel better.
And you are qualified to tell me that because you have no name and overinflated ego problem with unhealthy obsession to boot. Dude, find someone else to practice your inferiority complex on, I’m not interested. Go find yourself a name or take some nice picture, ok?
you said so yourself = “not sure what all those numbers are supposed to represent” … that is where the discussion ends … you of course can present your opinions further, no one can prohibit you to do so … I shall respectfully stop replying to your posts here
For sure the OP couldn’t go anywhere with photolab on its image using the only way photolab provides (raise exposure). But could with any other software. Others tried with local adjustment and couldn’t too.
Here is the subject of this topic.
And Noname gave an explanation. And explained its explanation.
