RawTherapee
RawTherapee copied to clipboard
wrong colors with 'Base table' option, 32-bit platform
If I open the "PA271580.ORF" RAW file with RawTherapee 5.2 on a 32-bit platform, then the colors are wrong.
(Perhaps it's a simple arithmetic bug that only shows up on 32-bit platforms?)
Steps to recreate the problem: 1. Install RawTherapee's 32-bit version. 2. Open the .ORF RAW file with RawTherapee. 3. Notice the colors are very wrong. 4. Disable the 'Base table' option. 5. Notice the colors are proper now. 6. Re-try steps 1 and 2 on a 64-bit version of RawTherapee, and observe that the colors are proper, regardless of the 'Base table' checkbox.
Please see the attached screenshots below.
Package versions: rawtherapee-5.2-2.fc26.i686 (on Fedora 26 32-bit) rawtherapee-5.2-2.fc26.x86_64 (on Fedora 26 64-bit)
The .ORF RAW file was created with an Olympus E-520.
RawTherapee already has a DCP profile for this camera, so I didn't have to go through the process of creating one.
Only if I disable RawTherapee's "Base table" option, then the colors are fine on the 32-bit system.
However, on a 64-bit platform (same RawTherapee version), the "Base table" option can be enabled, and the colors are fine.
RawTherapee's DCP profile for the E-520 contains a HueSatMap, as do all the profiles supplied by RawTherapee (I think), and I think the HueSatMap is fine (no problem there).
The issue seems to only occur on a 32-bit platform.
My guess is that maybe it's a just simple arithmetic error, where the code works as intended on a 64-bit platform, but not on a 32-bit platform.
Hope this helps, Jelle
PA271580.ORF: I had to upload the .ORF RAW file as a ZIP as uploading .ORF was not allowed PA271580.ORF.zip
rawtherapee-5.2-amd64-with-basetable

rawtherapee-5.2-i686-no-basetable

rawtherapee-5.2-i686-with-basetable

Possibly related to #4324.
@bughunter2 Please post your AboutThisBuild.txt
here. Thanks.
Not reproducible here on W10 with 5.3-533-gfe1ac7f60 32 bits which is the last version I can build in 32 bits. Neither with 5.2 32 bits. I can approximate with change of temperature to about 2600K. Perhaps something weird in the pp3?
@gaaned92
Not reproducible here on W10 with 5.3-533-gfe1ac7f60 32 bits which is the last version I can build in 32 bits.
Why is that?
I really id'nt mind as we are dropping windows 32 bit builds.
The builds made after simply don,'t start. If you want more detail, I can rebuild last dev and report.
I was just wondering, because 32 bit builds under Linux still work and should still be possible. Of course I'm curious... 😉
@Floessie
Please post your AboutThisBuild.txt here. Thanks.
I don't have it. If you're looking for information about compilation flags and the environment (and so on) of the system the package was built on, you could ask the Fedora maintainer.
Link to the rawtherapee-5.2-2.fc26 package page: https://koji.fedoraproject.org/koji/buildinfo?buildID=968495
Why do some package maintainers eliminate important informations at all?
One of the reasons is that some services download the source without the .git folder, making generation of that info not possible using out current build process.
Is this still valid?
I haven't built from source, so I can't test if it's still present. However, the comment by gaaned92 (about it not being reproducible) applies to 5.2 on Windows, while the bug report applies to Linux.
Also, I wanted to test for you whether the bug report is still valid, but Fedora have stopped distributing 32-bit builds of their OS/distribution, so I can't easily test newer versions of RawTherapee.
Still, if devs want to keep supporting 32-bit builds of RawTherapee, it may be worth it that someone takes another look at the bug.
Related: #4321 (discussion for dropping 32-bit systems support)