Fix wrong colors in ai_raw_denoise.lua#677
Conversation
8c536f1 to
a4dce23
Compare
|
Just tested and still getting (mostly) all black images. Tried a CR2 and CR3 and they both came back totally black. Tried a NEF night shot and it had some colored pixels. |
|
@wpferguson : Did you update models to the latest? |
|
@andriiryzhkov That was the problem. I had to rename the models directory and then do a fresh reload. A thought. Maybe the models should be put in the cache_dir. I'm running 40+ installations of darktable (daily driver, a couple of old versions, 23 development versions and 16 test versions) and they are all sharing a common AI model directory (~/.local/darktable/models). I wrap the various installations in a script that points to unique configuration/cache/image directories so that I can wreak havoc in a contained space and not break anything important or pollute another environment. |
|
@wpferguson : well, having shared models folder was a design choice, so with separate workspaces there will be no need to install once again. For the case you are describing, probably it would be good to have optional config key that can override default model folder location. |
That would work. I have scripts that build the environment and pre-condition the darktablerc file so I could just "fill in the blank" when I need to and not need a command line switch or even a preference. |
Small update that implements this customization. Not sure how it fits feature freeze though. |
This one was trickier than expected. The bayer rawdenoise model needs more preprocessing than the original script was doing, and the Lua tensor API didn't expose the per-channel ops needed to do it.
The two bugs
bayer_packsplits 2×2 blocks by position only, not by CFA pattern. On non-RGGB sensors (BGGR Leica, GRBG Canon, etc.) plane 0 was G or B – the model thought it was R and chaos followed.What changed
fc()– pure-Lua FC channel lookup.daylight_wb()– D65 daylight WB frommeta.color_matrix, same formula as the C path.(crop_y, crop_x)and re-crop so plane 0 always lands on R.{wb_R, 1, 1, wb_B}before inference, invert{1/wb_R, 1, 1/wb_B}after, so the saved DNG is un-WB'd camRGB.Dependency
Needs a new
scale_add_planesmethod on the Lua tensor binding (separate PR against darktable). The existing API has no per-channel arithmetic and no element-wise multiply, so applying per-channel WB without it isn't really possible.