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.
1 Like
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.