Manjaro Linux, AppImage of
RawTherapee_Beep6581_whitebalanceopt_release.AppImage
I assume that the CR3 from the EOS R7 is not fully compatible. I am able to fix images such as this one with the eyedropper, clicked on the background.
As can be seen, the jpeg has a good whitebalance.
This is a somewhat dated AppImage of a Pre-Dev test.
Replying to my own post.
Using a current release version of RT, exposure is either completely white, or sometimes seems to work.
It would be helpful to learn what is happening with R7 CR3 files on RawTherapee.
Alan
Hi @Alan_E_Davis, and welcome!
I am sorry, but I really do not understand your question — nor your own reply 
Please elaborate!
I just fetched an EOS R7/CR3 from raw.pixls.us and ran it through RT.
No problem at all.
Might you use some kind of compression?
Have fun!
Claes in Lund, Sweden
Are you using the 5.9 production release? I don’t think CR3 files are fully supported yet. I recently purchased a Canon R7 too and found other CR3 issues, namely there was no meta data available. So, I tried the Adobe DNG Converter which worked fine but there was the extra step converting the files. I have since installed a DEV build of RawTherapee from a few weeks ago and everything is working great now! You can download installable builds here:
The whitebalanceopt branch is 250 commits or so behind dev or release-5.10, I think @desmis was working on it back in July. I recommend using either of the other branches for CR3 support.
Thank you for responses. I am way behind.
Today, 23 December 2023, I downloaded the dev appimage. Crossed my fingers. Same problem. Very yellow cast.
Over time, I have tried several appimages from pre-dev; I think one of them worked ok. There are other problems, though, including black bars along an edge. Today’s dev build does present metadata, which I like. A day or two ago, I looked for the pre-dev builds, but they were inaccessible, as far as I could find. I’m not sure even the whitebalance pre-dev build was working for me.
I have seen comments that the inability to exif data was behind some bad white balance issues. This is not apparently the case for me.
I am capturing images through a microscope. The jpeg present a white balance that is faithful to what I expected, at least nominally.
What are your white balance settings? I opened a random R7 image in the development version and the “Camera” method matches the colors of the JPEG.
I removed all outdated pre-dev builds. The latest development build has everything those pre-dev builds had.
I am using Color Temperature adjustment. My microscope lamp, a 100W Halogen lamp, varies in color temperature as a function of voltage. I am adjusting color temperature per shot, in Live View through the computer. All is well on the jpeg: colors are pretty much as seen on the monitor. Every CR3 file, opened w/ RT, accept, IIRC, one random pre-dev build several months ago, take on a strong yellow-orange cast. The only solution I have as of now, is to adjust using the dropper tool on a place that should look white. Since I expose on
To continue:
I expose to almost overexpose the transparent part of a microscope slide, so in this case it is relatively easy to get an acceptable white balance. For other kinds of images, such as birds or flowers, it’s not so simple.
Experiments are waiting. I will take your suggestions into account.
If your goal is to match the white balance of the JPEG, set the white balance method to “Camera”. If instead you want an automatic correction, there is no foolproof algorithm available. RGB gray and Temperature correlation have their strengths and weaknesses and may not always produce acceptable results.
What do you mean by “Color Temperature adjustment”? Can you share a screenshot of your white balance settings?
Thank you for your response, all so many days ago; I must apologise for the delay.
I just tried several things, again. The problem I am having with the color shift when processing the CR3 files only happens, and always happens with files from my EOS R7.
As for jpeg files, white balance is set to “camera.” I have deleted all other versions of the dev / or predev appimage files, and all directories “RawT*” in ~/.config.
ART does not suffer from this problem.
As for Color Temperature, I think I was out in left field on that, because it is my capture methodology to use color temperature in camera. Could that be what leads me astray here? The preview image (I use Entangle under GNU/Linux for image captures under GNU/Linux).
Since I am photographing microscope slides of histological sections through a microscope, I can recover from this irksome problem by using the dropper tool, and clicking on a transparent part of the image, which should be rendered white in my estimation.
It has been problematic, even impossible, to process images of anything else.
Another problem with the binary RawTherapee, the newest under Manjaro GNU/LInux (ie., Arch-like GNU/Linux) has been a border of a strange hue, and bleached white images. I think efforts have been made to rectify the border problem.
ART, unfortunately, does not do a good job with Haze Reduction. DarkTable has been a black box, nonsensical controls, IMHO, but I am inclined to try again. If I can figure out how to save images in a sane manner.
BTW, I love the camera, but Canon has done it again, as it has with printers and cameras I have owned: protect itself from allowing the public to figure out how to use it’s drivers and firmware, to everyone’s detriment. What the heck do they think they have to lose? It’s a mob deal with the Big Two… I guess…
Thank you again.
Please show a screenshot of your white balance settings for one of the images that you’re seeing the issue with. It will be very helpful for us to understand what is going on.
I hope this will help.
The thumbnails may help to give an idea of what happens to the CR3 image once opened.
Thank you very much, by the way.
I can confirm that Canon R7 CR3 raw images returns the error message “EXIF data not available” when I try to open my Canon R7 CR3 raw images on my desktop. I suspect that is the reason for the poor WB. I was using Lightzone to open my raw images and didn’t notice a major problem. I recently tried Darktable and I’m not convinced yet as to how good the WB is.
I suspect that RawTherapee is still using DCRaw, and not the modified DCRaw where LIbraw is incorporated for CR3 raw images, hence why the error message pops up.
Take a look at what should be added to RawTherapee but may not be, see → HERE for Libraw Link
DCRaw has NOT been updated for over 5 years, hence no new cameras added.
RawTherapee uses a custom version of dcraw that does support newer formats including CR3s (since 5.8). @Alan_E_Davis has also tried a recent development version which can read the metadata.
Alan, it seems like RawTherapee does not pick up the camera’s white balance setting. 5000K is way too high for halogen lights, right? I will see if I can find anything suspicious using some random R7 images, but if you can provide a sample image exhibiting the behavior, that would give me a better starting point.
I attached one of my R7 CR3 files, although I don’t know if it’s the behavior you are looking for. I’m getting similar results with my Canon R8 images as well but I haven’t attached one of those, unless you want it.
Bald_Eagle_with_fish.CR3 (25.0 MB)
BTW, my Canon RF600 F11 lens is not one of the choices in the lens drop-down list.
Thanks for the image Steve. Comparing the white balance to the the embedded image using the development version, they look about the same. The color differences are mainly due to how the camera processes colors vs. how RawTherapee does it.
I checked the Lensfun database and it doesn’t have your lens, so that’s why it’s not in the list.
Thanks @Lawrence37 for the explanation!
I’m relatively new to RT and am learning it as we speak. The tutorials that I’ve found on YouTube and the Rawpedia documentation are very good. That said, I don’t have concerns about how RT does the camera color. I think I get good/very good results most of the time.
I figure that the missing RF600 F11 lens might be at the Lensfun database level, but it’s good to know of the confirmation. The closest lens is the RF800 F11, but that probably is not the best option either.
You should not choose a “closest option.” Either your lens is supported or it is not.
However, the process for getting a lens supported is not difficult and benefits everyone and ton of projects 
