As far as I can see it’s a problem with LR. Or a problem? You use a slider to the max, that’s mostly asking for problems. Can you tell us what values the pixels have with that purple color? Just curious.
George
I suppose what interests me is why you would use Lightroom at all, when PhotoLab is perfectly capable of doing the whole job.
What is it that you find lacking in PL?
@noname don’t butt in on this. Let @Merlinx63 speak for himself.
What do you mean by “value” ?? I don’t understand the question.
LR has everything I need exept DEEPPRIME !
PL hasn’t : friendly and smart masquing, smart import and catalog, quick preview (it’s sloooww even with my new PC 24 core, 64Gb …), smart import/export with Photoshop, correction tool friendly and efficient …
Also, is it possible now to make panoramic or HDR or Focus stacking in PL ?
Matthew 7:6
don’t you want to use Adobe’s new AI/ML NR in the recent versions …
I tried it, and it’s very promising, but DeepPrime make still a best job.
But I’m not professional or an expert in LR, maybe it’s possible to make the same result with adjustement after enhancing, but PL/Deepprime make the job in one click.
The original sky was clipping, value 255 255 255. Sometime one channel was 254. I just wonder what LR made out of that. That 's what I mean with values.
Not in this case. You start with PL as the raw converter. Work on your high lights in that converter. There is the access to the raw data. Your export to LR is a RGB image.
George
2 Likes
I already said :“LR which see pure white on the DXO DNG as a R=99.6% G=99.6% B=100%”
I was asking for pixel values, not white level values. I don’t know where you got these values from but I think it are the pixel values. Calculated back to 8 bits it means 254 254 255. But that’s not the purple place.
George
1 Like
Depending on setting !
If no correction, 255-254-255 (preview is white)
if I try to save highlight at -100 : 238-226-241 (purple on preview)
Between this 2 settings, the white sky comes more and more purple.
Ain’t that strange. High light recovering, lowering the exposure in the upper part of the histogram, shouldn’t change the relation between the channels that much. It’s really a LR problem.
If I do this in PL then 255 255 255 is changing to 253 253 253. If I take a place in the upper left the values 250 251 254 are changed to 239 239 243. Much more reliable.
I trust PL more then LR.
George
1 Like
topic starter wrote
when it comes to DNG then Adobe is the authority, not DxO ( more so DxO does proper job in the matter for other camera models ) and as it was clearly illustrated for people who can comprehend what is written DxO PL has a bug for in this case ( with “denoise and optical correction only” ) in linear DNG it produces for X-T5 camera model ( demosaicked values that DxO PL6 outputs to Linear DNG are scaled to values way below 0xc61d WhiteLevel tag values that DxO PL6 writes in that same Linear DNG for this camera model )
And topic starter clearly wrote
it is up for DxO now to fix the bug and make him happy with his totally legit workflow
Would you care to share the answer of the ticket when you get it?
This kind of things are alway’s interesting.
(if dxostaff don’t participate here to explain that is.)
I am just curious about the tru cause.
I don’t be an expert in any way but by simple test you can often find the global direction to go to.(often by excluding what’s not part of the problem. 
)
Because FRV is written around Adobe’s rawconverting, but not exactly the same i find it a good application for rudimentaire rawfile check: Raw histogram, channel under and overexposure percentage oversight, when the AWB of the camera f.cksup you can use the AWB of FRV to see which numbers would be fine to enter in DxOPl to correct that.
Quick shadow highlight check, DoF check, detail check that sort of things.
Diving deeper in rawfiles is often not needed.
One thing is some surprise, CA corection is part of optical correction module but aperently not part of the rawDNG corrections. (or they exclude only the manual correction settings)
Once i discovered a vignetting error with my g80 and rw2 files.
The panasonic g80 has vignetting coreection which i had active for the OOC jpegs but i discovered negative vignetting, lighter corners, which was strange because i thought vignetting correction is jpeg only and don’t effect rawfiles right?
In the exifdata there was a flag indicating vignettingcorrection was applied.
I made a ticket and in the end i found out that the g80’s vignetting correction was embedded in the rawfile. So DxOPL didn’t read that flag and applied again vignetting correction. Hence the lighter corners.
So nothing is in reality black and white. There is lots of grey.
The fact that DxOPl own exports don’t have the purpleglow doesn’t mean there isn’t a flaw inside dxo’s calculations but at the same time they arn’t oblicated to deliver a 100% compatible match for all other developers and in this case Adobe’s.
Sending a DNG from dxo to Silky’ix does also change the colors a bit.
(panasonics ires and idyn, camera jpegsettings, are read by Silkypix and also applied by silkypix on a rawfile. Same as the settings natural, vivid, monochrome and such.
Aka they read the exif data and assume you like to apply that also on your rawfile.)
So it could be also a form of automated correction in Adobe which is already done by dxopl and thus corrected twice.
For now you have a workaround apperently so that’s good.
You’ve got a scientific approach that explains a probable photolab bug, and a workaround to get around it.
Joanna has a practical approach that allows to find a solution that also gets around this bug.
But in the end, Joanna’s approach seems to preserve a better dynamic on the exported DNG:
0 → 255 versus 0 → 225 expressed in 8bit, or 0 → 65535 versus 0 → 57837 expressed in 16bit,
since the scale isn’t contained out of photolab in the DNG file with your solution.
In addition to providing a probably more interesting workaround to this problem, Joanna’s approach is neither pretentious nor pedantic.
I think you have very very very high self-esteem.
I hope you’re very young. This can be considered an attenuating circumstance.
3 Likes
Conclusion ?
Experience is better than theory for practical cases.
It is better to heal this problem in photolab as @Joanna did, than fake it by tweaking metadatas like you @noname did because Joanna way conserve a better dynamic in the exported DNG .
And more than that @Merlinx63 it is faster to do with Joanna solution :
It is even possible to create a preset that heals this problem for every photo taken with this camera with Joanna solution.
Just find once the right curve to compensate this and it is done.
Example of how to get rid of over-exposure and apply noise reduction.
I downloaded some sample Fuji X-T5 files, found one that was over-exposed and opened it in PL6.
Here it is with the highlight and shadow indicators…
If I exported this with only NR and lens corrections, I can guarantee I would have problems.
So, I apply my default preset, which contains just NR and lens corrections…
Then I simply reduce the top and increase the bottom of the Tone Curve by just 3 points…
Now, export to DNG with all corrections…
Now, open the DNG in PL6…
The only noticeable difference is that some colours are slightly more saturated, as can be seen if I turn on the shadow warning…
As it turns out, this is due to OOG colours rather than exposure, which has already been corrected, as seen by using the soft proofing tool…
This can be dealt with using the Colour Wheel…
Of course, I assume, this could be done from within Lightroom.
But, the most important lesson is that we may need to consider the colour space of the original RAW file and that of the exported DNG.
The sample file I downloaded was in the sRGB space, but the exported DNG ended up with the Display P3 profile, presumably taken from the monitor I am using.
Last consideration is whether you are viewing the image in PL6 with the legacy gamut or the new wide gamut.
Before messing about with kludging the white level, it could be worth checking for colour gamut and profile as well.
1 Like
my simple fix ( correct the tag in the linear DNG ) was for the exact topic’s starters workflow - remember ?
that’s it - no generalizations … of course he can change the workflow to start exporting linear DNG with other adjustments from DxO included…
Don’t restrain the informations of what I said :
Joanna has a practical approach that allows to find a solution that also gets around this bug which is better than yours because it leads to a DNG whith a better dynamic.
But you said to Joanna :
When its solution is better than yours. That is the point.
Your case seems hopeless. Live with it.
1 Like