Countdown to 5.12

Software RawTherapee
21

After starting RT I get the standard gearwheel icon in the bottom line. Some time ago, i think in 2024, I got the RT icon. Is this an intended change? If not, can someone tell me how to change that?

system info:
RT self compiled
Version: 5.11-208-g2a53427c6
Branch: dev
Commit: 2a53427c6
Commit date: 2025-04-01
Compiler: cc 11.4.0
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: 3.24.5
Lensfun: 0.3.95.0
libjxl: Disabled, Auto
Build type: release
Build flags: -std=c++11 -ffp-contract=off -march=native -Werror=unused-label -Werror=delete-incomplete -fno-math-errno -Wno-attributes -Wall -Wuninitialized -Wcast-qual -Wno-deprecated-declarations -Wno-unused-result -Wunused-macros -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags: -march=native
OpenMP support: ON
MMAP support: ON
Build OS: Linux 6.8.0-57-generic x86_64
Build date: Wed, 02 Apr 2025 11:59:00 +0000 UTC
Build epoch: 1743595140
Build UUID: bb83301a-c7a1-4b28-a753-c550302fe041

22

Hi @Kurt. I must confess, I’m having a hard time understanding the graphic. Are you saying the AppImage in my previous comment works?

@hholt We haven’t changed the icon from 5.11. Which Linux distribution / desktop environment do you use? Can you show a screenshot of what the icon looks like?

23

Graphic: sorry, I didn’t want you to have a hard time.
And yes: the AppImage works!

Aaaand: thank you for making it work. I appreciate it.

24

Thanks for testing and confirming! I’m very glad you caught this issue.

25

Jacques, I have a question regarding the translation.

TP_COMPRESSGAMUT_POWER_TOOLTIP; [...] This will increase the "color purity" or "saturation" once the image has been rendered through a display transform.

I guess that “display transform” is something that happens inside your algorithm. It has nothing to do with a transform to show the image on a monitor. Am I right here?

26

What about an improved, sharper preview image in one of the following versions, giving us at least some clickable options for faster rendering (no NR, sharpening method, …)?
As much as I like RT (years), I recently switched to darktable since the somewhat ‘blurry’ preview in RT puts too much stress on my ageing eyes, especially during longer sessions; I just couldn’t take it no more.

1 Like
27

@paulmatth

The answer to the question is anything but simple.
I’m linking again to the announcement I made in September 2024… Not much reaction.
Gamut compression

I’m also linking to the discussions we had with @Lawrence37 during the PR.
Pull Request Gamut compression

The subject is complex, but being afraid doesn’t avoid danger.

To summarize to the extreme:

The starting point is the camera’s maximum gamut, which (unless you have “inputs” at Nikon, Canon, Sony, etc.) is unknown. As a reminder, a perceived color is the matrix product of three concepts:

  • illuminant (daylight, LED, etc.)
  • the nature of the subject’s colors (theoretically measured with a Spectro) - independent of any illuminant
  • the observer - what we saw with our phisiology (eye / brain), or here “observing from the camera”… This is what is unknown. In the version we have put online the reference cameras are those (cinema) chosen by ACES…which indirectly refer to “Maximum distance limits”, but it’s not Nikon Z6II or Canon MKIII, etc.

The second point is what do we want to do? Is the compression to be used to produce a TIF to be edited in Photoshop or Gimp, or to be viewed on screen? It’s not the same thing at all. Also, if your screen is sRGB or Rec2020 (you’re lucky) this is the profile you need to choose.

The coefficients that appear in “Threshold” depend of course on the profile you want to go to. By default they are those of ACES relative to Aces AP1, which of course will not be “perfectly” suitable if you start from Prophoto (default working profile) to go for example to DCI-P3.

@Lawrence37 and I had long debates about whether or not to adapt these coefficients according to the users’ choices. The calculations are not simple, because what to take as a reference - ACES uses Colorchecker24 which for me has a big flaw, its colors are close to sRGB, so we “extrapolate”… and what’s more, we ignore the ‘observer’ of the cameras.

The answer could be found in the documentation with “recommended” coefficients, but on the one hand, Rawpedia is “at a standstill,” to say the least, and on the other, I’m a sick old man… So creating documentation that won’t be published or in X months is problematic.

Still, it’s a very good product—not because @Lawrence37 and I ported it to RT, but the basic concept of ACEs is more than relevant.

Paul, excuse me if the answer is not compact and simple

Jacques

28

What kind of softness are you seeing? There are several ways softness can occur, like this or this.

For the preview or when saving the image?

29

Thanks for the reply, the latter one. At 100% zoom level everything is fine but not below that e.g. image fill or fit screen.

Just for the preview (below 100% magnification).

30

Is it soft without any adjustments or does it only happen when you use transformations (like lens correction or rotation)?

Noise reduction and sharpening are automatically disabled below 100% magnification. If you’re experiencing poor performance, something else is causing it.

31

@Lawrence37 Can i ask why these 1.1 modules are automatically disabled below 100%
I know the the processing will be slower but surely we should be given that choice.

1 Like
32

Without any adjustments. In any other RAW converter I’m using this or other images look reasonably sharp without any adjustments.
Here’s a screenshot.

screen RT
screen RT2880×1920 572 KB

33

It goes way back, even before I heard about RawTherapee. My understanding is that computers were too slow to make noise reduction useful at less than 100% magnification. Of course, today’s computers are fast enough. Noise reduction in Selective Editing is active at all zoom levels. There’s an open feature request to add an option to enable the standard noise reduction and sharpening tools, but no one has gotten around to implement it.

That actually looks like the first one. Notice how the quick info text is blurry too. It’s being worked on and will probably be fixed in the following release.

34

@Lawrence37 @Varietea @ukbanko

Another problem for Denoise (including Selective Editing) is the evaluation of the noise measurement - which is done using “Mad” (Median Absolute Deviation) - which is calculated based on the active part visible in the image preview. This “Mad” value defines the “strength” of the wavelets. And it’s obvious that the part of the image seen in the preview is not the entire image, and therefore we end up with significant differences between the preview and the TIF/JPG output.
This is a “very old” problem (due to the 4 pipe-line and the construction of RT which dates from 2006) that I tried to solve about 12 years ago without any real success.

But I’m persistent, I’m working on the “captur-noise” branch, and maybe I’ll find a solution (probably complex algorithmically). The idea would be to calculate “mad” before Denoise, perhaps by implementing “tiles” or something similar. These values ​​would be much closer to reality (without being reality) - however, the computational areas must be large enough to allow for 6 wavelet levels - approximately 128x128 pixels or more.
This would allow for a denoise with more appropriate wavelet values. But perhaps this is impossible (or very difficult) to achieve, and the improvement will be negligible.

This “capture-noise” branch (which you can try by compiling, because I’m not at all ready to open a PR), which I’m working on “at my own pace,” is complex and should also improve “Capture-Sharpening” (Tab Raw) with a “presharpening denoise” (and perhaps others things) - Selective Editing denoise (by using ‘contrast threshold’…) and Selective Editing sharpening with a version of Capture Sharpening (non raw) that I’ve called “Capture Deconvolution”. This last part works correctly I think (but still with the problems of the 4 pipelines). But I too have vision problems with age :wink:

Jacques

3 Likes
35

I’m using Linux Mint 21.3 Virginia Cinnamon.
The icon looks like this:
RT-icon

The last appimage opens with RT icon.

I enjoy using RT for about 8 years, and as you see the wrong icon is no large problem. But for a release it’s probably a good idea to provide a professional look as far as possible.
If the problem is on my computer (or in front of it), I would appreciate very much a hint for solving the look.

36

Icons typically come from .desktop files. There are some standard locations for .desktop files such as /usr/share/applications. You are using a self-built version, so it’s likely your system is unaware of the .desktop file provided by RawTherapee. Packages provided by the operating system’s package manager install the .desktop file (and icons) in one of the standard locations.

One way to fix the icon is to copy rawtherapee.desktop from <your_rawtherapee_location>/share/applications into $HOME/.local/share/applications/. Edit the copied file with a text editor. Find the line that says with Icon=rawtherapee and change rawtherapee to <absolute_path_to_your_rawtherapee_location>/share/icons/hicolor/256x256/apps/rawtherapee.

37

I’m hoping to publish Release Candidate 1 within the next few days.

8 Likes
38

Many thanks for your efforts and all the others on here that make new versions of RawTherapee happen. I hope you all know you’re making a real difference in the world. :slight_smile:

2 Likes