Hi all, I installed the new release RT 5.9 and noticed that the color management does not work. I have a wide gamut display, colors are incorrect in RT 5.9, they are oversaturated.
I uninstalled 5.9 and reinstalled 5.8 again, it is all good with RT 5.8. Programs are running in M1 Mac mini, MacOS 11.7.4.
As I know in MacOS, you do not need to do anything in color management settings. I tried to do something in 5.9 this time, nothing changed.
Does anyone have the same issue?
What type of monitor are you having trouble with?
It is NEC PA242w in native ( full ) color gamut mode.
I’m on a MacBook Pro. I see the same issue with the built-in wide-gamut monitor. Images are over saturated in RT 5.9’s preview but the exported photos are correct. I tried it in RT 5.8 and everything looks fine.
Wondering how the release-5.10 branch looks on those screens… here is a link to my most recent build, RawTherapee_macOS_13.3_Universal_5.9-452-g88b0a5e45:
FWIW, I was having similar issues but they magically got fixed when I installed the dev version, I’ve been using the dev version since.
Hi Richard, the iCloud link leads to RawTherapee_macOS_13.3_Universal_5.9-448-gb2606673e and RawTherapee_macOS_13.3_Universal_5.9-452-g88b0a5e45
I installed the former and it works great, but crashes when you scroll to magnify IF I have wavelets adjustments on the image.
But if I go into prefs>performance and set threads to 5 or 6:
I’m not too sure of what ‘threads’ are, and what I’ve actually done here, but it seems to work!
Thanks, Andy. Please attach the crash report if possible.
Hi Richard, where is the best place to put the crash report - I saved it in text form.
@Andy_Astbury1 Andy, your report is much appreciated! I have rebuilt RawTherapee_macOS_13.3_Universal_5.9-452-g88b0a5e45_23DEC041825.zip which replaces both the previous builds in my shared folder mentioned above. Several libraries including libomp were updated.
I have a M1 Mini on macOS 13 and wasn’t able to crash zooming with wavelets as you mentioned. If the update to libomp doesn’t solve it, I may downgrade all the way back to libomp 11.1 which was not known to me to cause any crash.
BTW looking over the crash report I notice a commonality with threads 25, 26, and 28 for example, where a parallel task is raised and supposed to send the address of the wavelet decomposition table, but thread 26 somehow got a really low integer instead that didn’t make any sense to the app.
Hi Richard
That new build - threads at 0 (auto?), 47Mb raw file with wavelets, CAL and Retinex active + Dynamic Range Comp zooms in and out really fast on the scroll wheel now - with no crashes!
Cheers for that!
