I have this odd case where a few photos, normal size and high-res with my Panasonic G9 ended up with quite a significant green cast from RawTherapee, while others of the same scene and lens but slightly different composition did not exhibit this. The out of camera jpgs were also fine. Using Adobe DCP profiles exhibit the same thing.
Here is a google drive folder with the RAW and jpg files. I tried with RawTherapee 5.8 release and nightly builds. I normally use RT, but I also did a quick check in Darktable which also had a bit of a cast and Filmulator which did not exhibit the problem.
I just processed the file with a âNeutralâ profile, âWhite Balanceâ >camera, âRCD Bilinearâ and a +2.33 âRaw White Pointâ. It looks very close to your out of camera photo above. Iâm using the latest dev from Andreâ RTW64NightlyBuilds/ â Keybase.pub
Thanks, I appreciate you trying this, but the one you posted is from the file that does not exhibit the problem.
This one has the green cast: P1000191.RW2
This one doesnât: P1000194.RW2
I should mention my 5.8 release is the latest from the Ubuntu 20.04.3 repositories and the nightly (which hasnât changed in a while) is this one: RawTherapee_dev_5.8-2995-g166538d_20210614.AppImage from https://github.com/Beep6581/RawTherapee/releases/tag/nightly
There was a problem with greencasts and (some) Panasonic, as you discovered yourself.
Filmulator discovered it because it started to use Metadata that rawtherapee uses, and the problem cropped up.
I have the same problem with some dng files where I have to set the blackpoint manually with exiftool (but not Panasonic related).
I would be very surprised if this isnât fixed in rawtherapee, but then you really have to compile master. You sure you checked out the correct branch?
Otherwise cresting a github issue somewhere seems like the right thing to do. The wordt that can happen is that you are pointed to the fact that it indeed has been fixed somewhere, the best that can happen is that they didnât know it yet and you helped :).
It seems that different (generations of) Panasonic cameras need different logic to find the black point. In darktable, a fix that solved G9 issues broke the LX7. See:
I am slow to add issues onto github, and so try to exhaust forums first. But youâre right, they can just say it is fixed already or wontfix or whatever else the developers view may be.
I used the dev branch.
$ git status
On branch dev
Your branch is up to date with 'origin/dev'.
nothing to commit, working tree clean
I tried search Filmulatorâs code, but I canât even âfindâ the commit you linked. If I search for panasonic or âblack pointâ or something, I donât find that commit (apparently it does not search in commit-description ?!).
Looking at the code, it seems he added (back) support for reading black-points from the camconst file (camconst is a series of values Rawtherapee uses to determine stuff like white level and black level per camera model).
This code seems to have always been there on rawtherapeeâs side, so I donât know if itâs a bug in Rawtherapee or not. Could maybe just be a case of needing an updated camconst.json file.
I would make an issue, and if youâre nice, you add a section with âmight be relatedâ and then link to the earlier darktable change, and the filmulator commit. And then also add a line like âbut this might have broke thingsâ and link to the issue that Kofa gave you.
This way you donât send them on a search, but they (Rawtherapee devâs) can have a clearer picture if this is already OK or something new and which path to take forward.
As I understand it github only indexes and searches the primary branch. In this case the commit was the last one on the noisereduction branch and I am using the filmulator download that has noisereduction, I am not 100% sure this commit is in that release candidate build though. Just thinking it might beâŚ
