I am currently testing this dev version of RT:
RawTherapee_dev_5.8-3002-g4d1711412_W64_znver2_210622
I was editing an ARW file with a probably blown out sky. With an exposure compensation at -0.86 (and no other editing) the sky is rendered below 255, 255, 255 and with the same value for each RGB channel as show here:
As long as I know file browser just provides you with what ever jpeg is embeded in the raw, so if that jpeg (generated by the camera) has CAs or whatever that is what you will get.
The developer shows you the interpretation made by its algorithms (where you probable have corrected the CAs or other flaws).
Mica,
How much do you need to be able to go ;O)
Why chromatic aberration in the File Manager when nothing of the kind is visible in the Editor version of the image? Chromatic Aberration Correction is on Auto.
Fernando,
No, the rendering of the raw file in the File Browser can be changed with adjustments in the Editor, so it can’t be a fixed jpg.
Just for the fun of comparison. Here’s the same image presented in Bridge - large and small rendering (in this case it’s the native ARW file without any exposure reduction) :
mmm… I don’t know if we are talking of windows or linux, but I think it is quite the same.
In windows what file browser shows you is extracted by the raw codec you have installed, and the codec just shows you the embeded jpeg in the raw. Even if it creates a jpeg in its own, it never uses the edition you have done in your preferred developer (rawtherapee, darktable or whatever) as it has no way to know it or interpret the xmp associated with the raw, as each developer uses its own algorithms and parameters that have no mean for others.
The included jpeg in the raw is never changed since you take the photo, as a raw is a read only archive that no developer ever writes, just reads it (it would be quite dangerous for a developer write any part of the raw).
So what you are seeing in the file browser is just the jpeg included or an interpretation of the corresponding codec with default presets, nor the developing of the raw using rawtherapee.
Yes, what @ariznaf said. You might want to spend some quality time figuring out how to extract the embedded JPEG from the ARW file, then regarding it separately. exiftool will do this easily, from the command line:
I determined the -PreviewImage tag from an inspection of a .ARW file I’d previously downloaded for PlayRaw. If your .ARW doesn’t have that tag, you’ll need to use exiftool to list all the tags and inspect that list to find the appropriate tag.
If looking at @Eigil_Skovgaard’s first post you can see that he’s talking about RawTherapee’s internal file browser and not an external one.
The thumbnail in RT’s file browser is updated when you edit that image.
There’s an option in the preferences, although only valid when first loading a RAW, that tell RT if you want to see the cold RAW or the embedded Jpeg. This setting doesn’t “leak” or is relevant for the issue described by Eigil.
I also, at times, see the behaviour that he describes, but it isn’t always the case and I haven’t figured out yet why this only happens in certain occasions. I haven’t been able to find any mention of this in the docs and/or github either.
Ah, OK, show it is not the OS file browser.
The thread does not have the rawtherapee tag, and I don’t identify RT screens as I don’t use it.
I don’t know how RT works in that aspect. Darktable I think extracts the embeded jpeg while import (if you don’t overwrite it in config) but when you edit the image, it creates a new preview with the edit.
Here’s a video that shows this issue and the fact that it doesn’t always show up. All 4 RAWs have blown out bits, but only the first and third one show this reddish “issue”.
At the end I show that the thumbnails are updated when editing. It also shows that manually blowing out parts did not turn reddish in the thumbnail.
In the above video I did start with a neutral profile, but the result is the same if I use my own base profile, which uses a different mosaicing and has defringe and auto lens profile turned on.
Until a dev chimes in with deeper knowledge than myself, it may be related to the fact that the thumbnails are generated/«edited» in a different way than the main image in the Editor tab.
That is: most of the tools are applied to a smaller version of the raw image, and there are several tools that aren’t applied at all to thumbnails (e.g. the local adjustments tool), so the end result may very well look different in the thumbnail compared to the Editor preview.
And about Jacques’ video, those are all raw images coming from different cameras, so the first big difference between them is the demosaicing done with the camconst.json file values.
I can guess this behavior may be a problem for some photographers (pros?), but I don’t see a big issue there. You just have to be aware of it.
And yes, the moment a raw image is loaded into the Editor, you won’t ever see the embedded jpeg thumbnail, unless you «reset» all the edits (meaning removing the pp3 file).
Not a big issue - right. But the interesting part is - What is causing such a discrepancy?
The same with my 2nd example - showing an edited raw file in the RT File Manager - blurred! - while the TIF version next to it is nicely sharp.
All the shown thumb nails have the largest size available.
Xavier is right about the different processing. To generate the thumbnails, the raw image is resized before applying edits. For speed reasons, the resizing algorithm is not high quality. My guess is that there is some color fringing being over-represented in the resized image and that causes a color shift.
Soft thumbnails may be caused by lens distortion correction or some other geometric transformation. They introduce some pixel-level softness which show up well on the reduced resolution images used by the thumbnail generator.
But both annoyances should be taken care of, as the idea with the thumb nails is to render a 1 to 1 impression of the current state of the image - like it’s the case for most other raw editor browsers or file managers - not least as demonstrated with the screen copy from Bridge and here when opened in Adobe Camera Raw:
(I just changed/updated it)
It is also the reason I mentioned my base profile vs the neutral profile (i.e. demosaicing/defringing/lens profile).