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.
for millennia the assumption that the Earth is flat was ok for generations and generations in their practical pursuits … it still is for many
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 ?
Noname always explains its method.
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.
And here is approximation of that in Adobe Camera Raw.
It is what I would expect from a photo like that. I don’t see a problem with either Adobe or DXO.
If there is any kind of loss of details on numerical level, I think its the king of people with no names obsess about, but I see no reason to.
I mean nothing. Just need to understand the facts.
Are you always using raws from the same camera(s) ?
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.
in the eye of the beholder… that is why there are tools like rawdigger, etc
Only if you are solving math equations not taking photos. Perhaps you are in the wrong department.
we are talking about bugs , not about taking photos … plus no raw file shared → baseless statement
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.
Fair point. I have complained to Adobe, and other companies for their bugs for a long time, and they rarely get fixed unless its part of their interests or really strong backlash. This is common to many companies. I only knew few smaller companies that take into account most user requests and bug reports but usually they are one or two team crew.
warning(‘off’, ‘imageio:tiffmexutils:libtiffWarning’ );
warning(‘off’, ‘imageio:tiffutils:libtiffWarning’ );R = Tiff(‘z:\RAW01384.DNG’,‘r+’);
setSubDirectory(R,getTag(R,‘SubIFD’));
M = R.read();
M(:,:)=512; % all frame to black level
M(250:250+4800-1,300:300+5000-1)=uint16(repmat(reshape((repmat(linspace(512,11681,2500),2,1)),1,5000),4800,1));
M(250:250+4800-1,5600:5600+2000-1)=uint16(repmat(reshape((repmat(linspace(11682,16383,1000),2,1)),1,2000),4800,1));
R.write(M);
close(R);
we create 2 eq.DN-scales , one from black point to 11681 and one from 11682 to clipping = https://app.box.com/s/0h1i1147ez7xcz2cdsyeiaqzgd5xf0wq
we then export to linear NC / DOCO DNG left scale has all data unclipped and right scale has all data destroyed
adjustment to the tentative theory ( based on A7R2 camera model investigation ) is ( note : DxO probably switched to correct way for some camera models - like may be for Sony A1 / where as noted above they also process ARW differently than DNG / - but not for all models otherwise this topic 'd not exist )
step 1 : DxO finds “true” clipping point ( based on metadata or whatever else they use )
step 2 : DxO scans the image frame for sensels within ~0.5 stop ( may be +/- for different camera model, etc) below the point found above in step 1
step 3 : DxO set its own clipping point to the min DN values found in at least certain amount of sensels found in step 2 / we shall next find what that min qty of sensels is /
step 4 : [ by the end of the demosaick process , we can’t find out more precisely ] DxO destroys all data above their own clipping point from step 3 - data below that invented clipping point lives unmolested
…
step x : DxO exports linear DNG ( NC = “no corrections” preset / DOCO = “Denoise & Optical Corrections only” ) without scaling data up to the values of 0xc61d WhiteLevel tag that they are writing in that linear DNG ( OR w/o adjusting the values of 0xc61d WhiteLevel tag down to the end result of their own clipping )
Looks like the OP problem was fixed in PL7.5 as a part of ‘Minor bug fixes and improvements’.
yes – now showing a smooth transition and no more pinkish
Hardly a minor bug fix! But I’m very glad to know this and hope the fix has been implemented completely.
An old but interesting document about this issue :
The conclusion may surprise but it’s related to rather old APNs. Anyway, this text will help understand what’s going on when a RAW file is decoded (or generated) with wrong whitelevel values.
