Checking the Leica file in RawDigger, I found histograms that look like clipped highlights, but the peak values are 3 points below “White” as put down in metadata. Therefore, PhotoLab should have no reason to tinker with highlights, but it does. It doesn’t with highlights that are really clipped and have the corresponding peak at 16383/16383.
When I take one of my clipped CR2 files, the exported DNG file has highlight values that are a) the same for R, G and B (expected) and b) lower than the max. value of 64K (unexpected) - but only with “No Correction” applied and/or exported with “Optical Corrections Only” (unexpected again).
Be careful to compare the pixel values in a linear dng and a normal rgb. In a normal rgb the linear values are gamma and color corrected. A linear 225 will become 240 with a gamma of 2.2. And then the color corrections. A value of 128 will become 186. I’m not sure what to do with the figures of RawDigger.
the difference between linear DNG produced as an intermediate step for a specific workflow by whatever software and raw files produced by camera’s firmware ( DNG or NOT) is that software developers ( at least those who are not in the name only ) do test raw files produced by camera’s firmware to find out where clipping is ( not only relying on metadata ) - but with linear DNG they have to rely on metadata as they can’t possibly test ( and they don’t ) all for all errors/bugs with how the data was generated
Wonderful, village idiot (your avatar’s claim, not mine), so you think you found a bug. Open a bug report with DxO. Beating this subject to death in this forum will not cause the bug to be fixed. It’s tiresome to keep harping on the same stuff that most of us don’t care about because we will probably never run into it. Not to mention that your, shall we say, less than engaging ways greatly take away from any credibility you may otherwise have, but that’s another story.
Noticed this on a lot of images from my GM5 coming back from backpacking this week in DXO 7.8. I seem to recall having this problem in darktable back in the day with this camera. I have never had the magenta highlights appear in raws from my Olympus cameras, only the Panasonic. The magenta is not present on the camera processed JPGs.
Is there a “fix” in the works for this? Like a “magenta highlight correction tool” or something? I’ve tried lots of ways to manipulate this, but it ends up adversely effecting the rest of the image in some cases.
Lets see if this works now… Attached is a raw file from my GM5. This file appears correct in FastRawViewer, but has magenta highlights in DXO. I have not found any way to process this out. Nearly a decade with DXO, purchased nearly every update, I’d like to see this “bug” fixed… Hopefully this sample can help towards that end.
I’m not a FastRawViewer user, so I won’t elaborate on this. It seems to read the raw file correctly, not the embedded JPEG. But the description of the problem makes me a little suspicious: it’s very similar to what we see when reading an embedded JPEG.
If I open the raw file in ACDSee, which allows you to display either the embedded JPEG or the demosaiced raw file, I see that:
The embedded JPEG has no magenta cast in the highlights (the sky in particular). This is normal since that’s what the camera processes.
The demosaiced raw file has a fairly significant magenta cast in the highlights of the sky.
If I open the raw file in ACR (Lightroom/Photoshop), there’s also a magenta cast, but lighter. On the other hand, if I use an automatic setting (light, color), there’s a significant magenta cast.
So I don’t think this is a bug specific to DxO Photolab, but rather a problem specific to this camera model.
But I think there should be specific settings in PhotoLab to mitigate this problem.
FastRawViewer has a “Switch” to go back and forth between imbedded, JPG, external JPG, and actual raw (debayered) view. In this case, the directory I am viewing this in has no external JPG for this image, so it just toggles from imbedded to raw. In this software there is no magenta highlight problem on either the raw or imbedded image with any of these files from the GM5.
I have also observed the magenta highlights in some software, but not in others. I believe the software that is interpreting the highlights incorrectly is probably a chunk of open source software that was barrowed over a decade ago to be put to use in DXO
Rawtherapee’s first couple controls around exposure appear to be related to giving the editor some latitude to adjust specifically the effects of “blown” highlights on the image.
I would be extremely surprised if DxO used old pieces of open source code in its demosaicing engine! Let’s be serious…
That doesn’t mean there isn’t a problem with this camera/sensor. But if there is a problem, it’s not specific to DxO, since I’m seeing the same magenta drift with Adobe.
If you think there really is a bug, the best thing to do is submit a request to DxO support.
What we can do is find a workaround or settings that minimize this drift.
Based on this raw file, I applied the DxO Standard preset, with the additional settings highlighted. This is, of course, a personal interpretation…
The view is a comparison view with the uncorrected original on the left.
My understanding is that it’s pretty common for a raw viewer/editor to have a variety of debayering/demosaicing “engines” for all sorts of different sensors, since the same algorithm would not serve all camera sensors equally well. It would stand to reason that the engine used for this old camera would still be derived from work done around the time the sensor came out, and would retain any bugs from that time. I don’t understand the “lets be serious” comment. The same problem has existed in some software but not other software for a decade. I believe there’s probably an origin story to it.
If this were being caused by the camera, then how come the camera processes JPG’s with no magenta in them from these same raws? There is a way to debayer/process/interpret these raws that does not cause the magenta highlights, but that isn’t being done correctly in all software.
