RYYB or RGGB is the same. First of all, none of them is what they say (there is no green, blue, red, yellow or whatever, it’s only arbitrary spectral slices), but then the mechanics are the same : multiply channels by wathever coefficients you have. If you have the right coeff for the right channel, you absolutely don’t care about what this channel is.
I did not test, but one reason for this issue might be, that RawTherapee always uses the D65 matrix inside a DNG file (if available). Maybe for this kind of files it would be better to use the Standard light A
matrix (which is available in this file btw.) ?
Is there a way I can test it myself?
Search dcraw.cc for
if( get2() != 17 ) // 17 is Standard light A
and replace it with
if( get2() == 17 ) // 17 is Standard light A
I’ll give it a shot. Problem is that my own builds are all borked right now, so I need to figure that one out first.
So this changes something. Colors are different and Temerature/Tint are read out as 1706/0.173 rather than 1500/0.87. Very promising!
Now the only problem i am left with is that my own builds don’t work properly.
Stable build, downloaded online: https://i.gyazo.com/63b5477eec8c933b7cbcec9ee5b31cf1.jpg
My own build of the latest data, no modifications: https://i.gyazo.com/c6552f7906d609b2f5c6ba88b4733bb8.jpg
Build with the modification as suggested above: https://i.gyazo.com/191274d92f3fd3aa732852749d6ffefc.jpg
You can see that there is a weird purple tint on my own builds. Any ideas how to fix that? This is my first time building anything, so it might just be a silly rookie mistake. I build for Windows 64 bit, simply following the guide on RawPedia.
Did you build using gcc 10.1? That’s a known issue. Just downgrade to 9.3
Edit: for reference:
It works also with gcc-10 of you disable the optimization option from the quoted bug.
Compiling with fno-tree-loop-vectorize is fine
I know that, as it was me, who bisected the compiler flags to that point. Though I don’t think we want to disable this vectorization…
Sure, it’s just a quick fix for the OP in case he cannot roll back the gcc. I have the problem because i compile on Windows with msys2. Once gcc was updated, I could no longer rollback.
I’m on msys2 as well. Rollback is no problem on msys2
Interesting, it did not want to do it for me. Can you please share what procedure have you followed to rollback?
Sure, do you still have gcc 9.3 in /var/cache/pacman/pkg/ ?
ls /var/cache/pacman/pkg/
yes, it is still there:
ls /var/cache/pacman/pkg/ | grep -i gcc-9.3
mingw-w64-cross-gcc-9.3.0-1-x86_64.pkg.tar.xz
mingw-w64-x86_64-gcc-9.3.0-1-any.pkg.tar.xz
mingw-w64-x86_64-gcc-9.3.0-2-any.pkg.tar.xz
pacman -U /var/cache/pacman/pkg/ mingw-w64-cross-gcc-9.3.0-1-x86_64.pkg.tar.xz
Same for the other files, should revert it then
No luck…
doing:
$ pacman -U /var/cache/pacman/pkg/mingw-w64-x86_64-gcc-libs-9.3.0-2-any.pkg.tar.xz
loading packages...
warning: downgrading package mingw-w64-x86_64-gcc-libs (10.1.0-2 => 9.3.0-2)
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing mingw-w64-x86_64-gcc-libs (9.3.0-2) breaks dependency 'mingw-w64-x86_64-gcc-libs=10.1.0-2' required by mingw-w64-x86_64-gcc
trying to remove first gcc I get:
$ pacman -R mingw-w64-x86_64-gcc
checking dependencies…
error: failed to prepare transaction (could not satisfy dependencies)
:: removing mingw-w64-x86_64-gcc breaks dependency ‘mingw-w64-x86_64-gcc’ required by mingw-w64-x86_64-libunwind
:: removing mingw-w64-x86_64-gcc breaks dependency ‘mingw-w64-x86_64-gcc’ required by mingw-w64-x86_64-uasm
and it continues like this.
I guess I will stay with the removed optimization and gcc-10 for a while. I did not noticed any performance hits anyway.
The good part is that I can report when the problem no longer appears with gcc-10
by the way, sorry @MakeItColder for hijacking your thread
You need to downgrade the
Package as well. Have a look for the filename in cache folder. It also took a while for me to solve all the conflicts.
@Daniel_Catalina I had the same issues. You need to force the downgrade of gcc
and gcc-libs
(and maybe some others that I forgot) by setting -d
which skips the dependency checks.
gcc indeed was the issue causing the purple tint. Unfortunately I still cannot set the white balance under artificial light, even with a camera profile that accounts for the RYYB filter.
when yyou have interdependant packages, downgrade in the samle time
pacman -U …