I’ve been using Rawtherapee for a few years now (currently on openSUSE Tumbleweed), but after an update last week, all my RAW files look purple, without having touched the .pp3 files, independent of whether I’ve processed them before, or whether they’re new and I’m opening for the first time.
The weird thing is that I don’t even think that Rawtherapee is to blame directly, since it was not updated: I was running the standard YaST software update which updates all installed packages if possible. There were 1700 updates but thankfully my root directory is using BTRFS, and there’s before/after snapshots around the update. A comparison shows that Rawtherapee itself (anything int /usr/share/rawtherapee) was not modified. However, the issue only affects Rawtherapee, afaict: The same RAW files look fine in Darktable, previously exported jpegs look as they should, but if I use RT on RAWs which I processed last week in RT, the resulting jpegs look just as purple as the RAWs did in RT, which means it’s probably not “just” a display colour management issue, either.
… does anyone have an idea where to start looking for a solution? Is there maybe some 3rd-party library from which RT is getting some camera-specific settings for RAW files? Or something that could have happened in my userspace config? Sadly, I have no snapshots of my home directory
If this helps: I’m using a Canon EOS 6D, which uses .CR2 files, and they’ve been working just fine in both RT and Darktable for several years.
Addendum: I have seen this thread: Purple dng rendering
And the the colours are somewhat similar, but if it’s an issue with RAW black levels, then I don’t get why RT would have forgotten about them between one time I use it and another…
Version: 5.8
Branch: 5.8
Commit: 9a9e0acbf
Commit date: 2020-02-04
Compiler: cc 10.1.1
Processor: x86_64
System: Linux
Bit depth: 64 bits
Gtkmm: V3.24.2
Lensfun: V0.3.2.0
Build type: release
Build flags: -O3 -Wall -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -std=c++11 -Werror=unused-label -Werror=delete-incomplete -Wall -Wuninitialized -Wcast-qual -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -O3 -DNDEBUG -ftree-vectorize
Link flags:
OpenMP support: ON
MMAP support: ON
So apparently it was compiled with GCC 10, -O3 and -ftree-vectorize, which fits the bill for the github issue you linked to.
It is a little weird, though, that this build worked for me all the way until 2nd June (the date of the last set of exported images without problems), and the issue only showed up on 6th June, when RT itself was not updated in between…
I’m pretty sure as there are zero differences shown by Snapper (but loads of differences on other packages)
… however I just realized there might have been another update before, for which I’ve deleted the before/after snapshots because I’d run out of space for snapshots… so actually I might be wrong there, and I’m also unable to determine if this is so.
Dangit
I suppose the short-term fix (unless I want to compile RT myself, which I don’t) is to revert to an older version?
I don’t know whether this will work, as older versions (built with gcc 9.3 or so) also may require a corresponding version of gcc-libs which most likely on your system now is also 10.1
Compiling RT yourself will fix the issue (at the cost of some performance loss) because @Thanatomanic has made a workaround for this gcc 10 thing.
I am still trying to make a reduced test case to file a bug against gcc. Turned out it’s not so easy
Turns out I have both gcc9 and 10 installed, so I just downgraded to RT 5.7 from the OBS:graphics repo (thank goodness they still had not updated to 5.8 as most repos keep no previous versions…), and the issue is gone – fingers crossed this can be resolved quickly in 5.8 because I bet there are more users looking at their RAWs and wondering right now …
Is there anything I can contribute to helping with this? I’m not used to compiling stuff locally and not familiar with C++ or Linux build systems but if you need another machine with different library versions to test on, or something else you find useful, please let me know.
This can not be resolved in 5.8 release at all (only for 5.8 nightly builds). The only way to solve it is to get the gcc bug fixed (at least we think it’s a gcc bug) or (as long as the gcc bug is not fixed), using a nightly build (for example an appimage)
Well … the original bug may be in gcc but what I meant is that the issue can hopefully be solved quickly enough that not many users start to either downgrade, recompile or just get generally annoyed or maybe start messing up their photos in an attempt to correct for the “wrong” colors in their RAWs or something …
It is already solved in current dev branch of RT (by the workaround mentioned above). Bot once a RT version is released (and RT 5.8 was released a while ago) we don’t change the source of the released version. A release is fixed and will stay fixed.
I used obs://build.opensuse.org/graphics, which still carries the 5.7 version – mostly because I had not used appimage packages before and didn’t want to open that can of worms now, after recently having tried out Snap and Flatpak and being fairly dissappointed with them, and how badly they integrate with openSUSE and Plasma/KDE.
However: I’ve just downloaded the appimage linked by @Carmelo_DrRaw [1], and it works just fine. I first installed appimaged (from default openSUSE repo), so when I first run any appimage, it offers to set up desktop integration. Now the dev version of RT shows up as "rawtherapee (appimage) in my launcher, and it even shows up in the Raw developer application list in the Shotwell preferences – great!
Drawback: It did not recognize the preferences I had set in the “regular” version. My preferences are pretty close to default, though, so no big issue for me.
==> just switched to the nightly build via appimage, and all’s well.
[1] you’ll need the one named “RawTherapee_dev_5.8-xxx-xxxxxxxx_.AppImage”. The one called “RawTherapee_5.8.AppImage” is just the regular 5.8 release.
This is done on purpose: we didn’t want to “pollute” the standard preferences with those from AppImage development builds, in case there would be no backward-compatibility with official releases…
Very understandable for a nightly build/dev package.
Ahh, I just found where they’re stored[1], so I could run a diff, or probably just copy the files across if I wanted to.
By the way: What is the reason why previous versions are usually not kept in repos these days? I remember being able to switch to older versions of packages if the latest one didn’t work for me. These days, if I spot the problem in time, I have to roll back the update (thank you, BTRFS!) and lock the package, but there’s no way (I’m aware of) to re-install any but the latest version of any package on offer.
