I’ve just tried RT for the first time (on Ubuntu). Based on what I’ve read, I believe the answer to my question may be “it’s not a bug, it’s a feature,” but I want to confirm.
When I open an image for the first time (I’ve tried this on various images, and it’s always the same), before changing any settings from the defaults, it appears noticeably soft in the preview; however, when I zoom in to 100%, it looks sharp. I notice some improvement by going to Profiled Lens Correction and switching from Automatically Selected to None - but by default, the preview is always soft. Is this expected behaviour?
I’ve used similar software (Lightroom, Capture One, darktable) and never experienced this behaviour. Unfortunately, this is a deal breaker for me - I need my images to be sharp at all times, or I find it disorienting.
@Graham_Lavender Welcome to the forum! Could you please provide us with more info? E.g., which version and where you downloaded it from, and screenshots.
Thanks - you just helped me solve it! I was using 5.6, which is the version available on Ubuntu 19.10 through the ppa, but I just tried 5.7 via appimage, and it’s much much better.
I still find it odd that this was happening on 5.6, but I’m now satisfied. Thanks again!
In order for the preview to be responsive, RawTherapee uses that very preview image you see at the very resolution you see - small - to show what the tools do.
For example:
If you were to convert a raw file into a full-sized image, then apply exposure adjustment, then noise reduction, then rotate it 5°, then display this image in a window 1000px wide (i.e. downscale the image to 1000px wide), you would end up with a crisp and detailed 1000px wide image, but it would take a long time to do all this.
If you were to convert a raw file straight into a 1000px wide image, apply exposure adjustment, skip noise reduction, rotate it 5°, and show it in a 1000px wide window, the whole thing would work must faster, though the end result would not be accurate nor as sharp.
As such, the slow-but-accurate pipeline is used when saving the image, but the fast-but-sometimes-inaccurate pipeline is used for the preview.
Thanks for following up. I read about this in the docs, and I’m still a bit confused. Perhaps you can straighten things out for me.
I certainly understand that software development includes many compromises and trade-offs, and what you’ve explained makes sense: the preview sacrifices accuracy for speed. My question is: why does other software, including Lightroom and darktable, not need to make the same sacrifice? Is it because RawTherapee is optimized for less powerful computers? I find the preview in these other programs to be both fast and accurate on my desktop, while there is a slight (but acceptable) lag in darktable on my laptop.
Don’t forget working profile → display profile transform. I’m finding that to be the slow part of my pipeline-to-display (well, unless a denoise is in the chain, I need to optimize those, someday…)
In my hack software, I was waiting until after the crop for the display window to do the colorspace transform, but I found doing that with 8-bit numbers made the display horribly posterized in the shadows. So right now, I do it with the internal floating point image, well ahead of crop-for-display, but that’s on the whole image, thus slow.
I’m ruminating about such here so the OP can consider what sort of things are traded in the pipeline to display. @Graham_Lavender, what you’re seeing are the results of different trades, different priorities. Believe me, LR traded off something to get faster display. Me, I don’t use RT regularly, but I find its display to be quite responsive to interaction, even in the face of lots of enabled tools. That might be commentary on my hack software, which is like beating oneself in the thumb with a hammer - it feels good when you stop.
I’m sure all software makes compromises.
Adobe solved the problem by drowning it in 21 000 paid employees.
@heckflosse makes mind-boggling speed and memory optimizations using better CPU code. Maybe some day RawTherapee will run on the GPU, though even then there are limits as to what can be optimized and what cannot.
Thanks for sharing this, Glenn. As a non-technical person, I don’t understand all of it, but it still helps me appreciate the work and challenges involved in this remarkable piece of software.
