RT Slow on Mac OS with default monitor profile

RawTherapee 5.8 is running very slow on Mac OS Catalina with the default monitor profile enabled. Switching the monitor profile to sRGB IEC61966-2.1 immediately improves performance. Just about everything gets faster - panning around an image, scrolling through thumbnails, scrolling panels, dragging sliders, processing. All of these are very laggy with the default ‘Colour LCD’ profile selected.
I have been working mainly with Canon S95 raw files, but it’s the same with all files I have tried.

So there seems to be some sort of bottleneck when using the Colour LCD profile. Switching to sRGB sorts out the performance, but clearly it’s not a solution, because all the colours change!

Catalina 10.15.7
Macbook Pro 13 inch 2017
Intel Iris Plus Graphics 640 1536MB (2560x1600)

RT info:
Version: 5.8
Branch: 5.8
Commit: 9a9e0acbf
Commit date: 2020-02-04
Compiler: clang
Processor: generic x86
System: Apple
Bit depth: 64 bits
Gtkmm: V3.24.2
Lensfun: V0.3.95.0
Build type: release
Build flags: -Wno-deprecated-register -Wno-unused-command-line-argument -std=c++11 -std=c++11 -mtune=generic -Werror=unused-label -Werror=delete-incomplete -mmacosx-version-min=10.9 -flto -Wall -Wuninitialized -Wcast-qual -Wno-deprecated-declarations -Wno-unused-result -Xpreprocessor -fopenmp /opt/local/lib/libomp.dylib -I/opt/local/include -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags: -mtune=generic -headerpad_max_install_names -flto
OpenMP support: ON
MMAP support: ON

My initial guess is that the lcms2 library is at fault here, it is known to be somewhat slow. However, I have no way to test this as I am not a mac user…

It’s a known Gtk3 issue. In fact, there is a difference between Gtk color space (RGB) and Apple native one (P3). So a conversion between color space is made by MacOS rendering RawTherapee application, which costs a lot of resources. To avoid this, normally only modified app window parts are redrawn but the quartz backend in Gtk3 is not really optimized… (full app window is redrawn just moving mouse on it…). Hopefully quartz backend has been completely rewritten/optimized in Gtk4. Switching RawTherapee to Gtk4 should improve this situation.

That’s also my thought; lcms2 now has an optional plugin that speeds up floating point-based transforms, and those are quite fast. So, it could be the difference between one instance using lcms2 with fast_float, the other without…

Thanks for all the replies. I hope the developers pick this up and find a solution, because it’s going to put a lot of Mac users off using RT as it stands. I nearly gave up on it myself as it’s almost unusable with the default monitor profile. I’d like to use RT for the full editing process, but at present, I either have slow performance or inaccurate colour, so at present I’m just using it for demosaicing, capture sharpening, noise reduction and removing baked-in lens profiles before moving to Adobe, which isn’t a great workflow.
It’s an amazing program otherwise - keep up the good work!

You should really calibrate your screen, then you’d have a really accurate profile and you wouldn’t be using the default. I highly doubt the default profile is tuned well for color fidelity.

There is very little we can do atm, since it is not RawTherapee that is causing the slow-down. Upgrading to GTK4 as a potential solution as @Pandagrapher suggests is not something I see happening within 2021…

1 Like

If you calibrate the screen with something like an i1Pro Display it will produce an icc profile in your users>Library>ColorSynch>Profiles folder and THAT will be your system profile - this might well get rid of the problem.

Under RT Prefs>Color Management you can point RT to that folder.
But the dialogue also shows that currently RT can’t use the default system profile - or so it says!

One thing I will say, I have the very same MacBookPro and the monitor profile is pretty much sRGB equivalent anyway, so from a colour PoV, allowing RT to use sRGB won’t make any difference to your work.

Other workaround: You can play on screen scaling because reducing it improves also RT performance.

Personally, I don’t use the Apple recommended one but the one just above which increase font size. With that, RT interface is just a little laggy but I can use it to treat my pictures while keeping default screen color space.

Thanks for your suggestions. Yes there’s a possibility that making a profile may improve the performance, but I don’t have any profiling hardware and I’m not ready to buy some for the purpose of making RT run faster. Plus, it’s not definite that it would improve things. In the colour management preferences, there is some text saying ‘Due to MacOS limitations, only sRGB is supported’, so maybe that means no other profiles would give good performance - I don’t know. I have worked on profiled screens before, and I didn’t find enough of a benefit to warrant spending the money, to be honest.
My experience of the difference between sRGB and the standard profile is that it’s quite significant - colours are much more saturated when using sRGB, probably because it’s a smaller gamut.

Thanks - I tried changing the scaling setting, but it made no real difference unfortunately.

Thanks. All way above my head, but sounds plausible. I wonder if it’s possible to ‘translate’ the P3 space permanently into a profile which can be read quickly by RT, and which approximates to the same colours? The sRGB monitor profile is giving me substantially more saturated colours. I know that the default profile will not give me ‘correct’ colours, but it’s what I’m used to and just want things to stay consistent between applications.