Again just to show that this doesn’t happen for me and so must be a hardware or WinOS setting or DT setting…see the attached video. I first do the image with a very basic workflow…only modern WB and cycling the options and then with the xmp provided by the poster and I do see an artifact but in the first case but with the surfaces option and I don’t have the disappearing image/black screen…
I also just downloaded the nef and xmp and opened w/o a problem.
openSUSE Tumbleweed
dt 4.1.0+100~gc2a9e1ccb
It’s a windows problem.
Are you using msys2? Up to date? Do you have a clean git clone?
Everything is fairly recent. I had no issues with 4.10 _59 and now I think i made this video with an newer version…
I just don’t get this black screen that was mentioned.
I am not sure what details would help. I can run a debug I guess and see how it might be different from those that are finding the issue in Windows…
I know you do different builds with different repositories, so i don’t know if that is playing a factor.
At least 3 windows users (including me) have experienced the issue on windows. I shared that it seems like a non numeric value is being entered into the values.
Currently just off the master…I did merge the new HR branch but that was after I tested it… I do use msys2 and I just use the build script to build it…ie build.sh…
I will try to look at the best way to summarize my build and OS settings in detail incase that heips…
I have this too, and have it since 3.8+ somewhere
Never thought much of it.
I don’t know if my win10 system has it , but my current win11 system has it. Always Nvidia based though (gtx1060 desktop or rtx3050ti laptop)
Does changing your display profile make any difference?? Just throwing things out there… I will redo what I did in the video with debug on. This should provide a log that does not have the same lines as a log that comes from a fail at least one would think…this still might not show much if the issue is an OS setting… I know i did go through my OS when I got the new PC with Win11 and made sure all the color management settings were manually selected by me to be sure I was getting from the OS what I was expecting…
Just tried my old PC at work and again no issue like this on the few images I tried from a playraw folder I have…its an older core i7 intel with Win10 Pro and 16GB memory and old GTX 745 Nvidia card with 4GB…
I can toggle back and forth in CC and I can’t trigger the black screen…
@priort can you try with denoise wavelet on? Or anyone else on windows?
Ref: https://github.com/darktable-org/darktable/issues/12197#issuecomment-1200338607
Still no issue. I went back and downloaded the image and the original xmp from the OP and found no issues… I see that it was using non local means…switching it to default wavelets did not cause any issues either…sorry I haven’t had time to do any debug log. I might later today and I will post it so you can compare with the sections on yours that you suspect…
… I see this with
this is darktable 4.0.0
copyright (c) 2009-2022 johannes hanika
darktable-dev@lists.darktable.org
compile options:
bit depth is 64 bit
normal build
SSE2 optimized codepath enabled
OpenMP support enabled
OpenCL support enabled
Lua support enabled, API version 8.0.0
Colord support enabled
gPhoto2 support enabled
GraphicsMagick support enabled
ImageMagick support disabled
OpenEXR support enabled
on
System:
Host: Rechner Kernel: 4.19.0-20-amd64 x86_64 bits: 64 compiler: gcc
v: 8.3.0 Desktop: Cinnamon 3.8.8 Distro: Debian GNU/Linux 10 (buster)
Example is with “detect from image surface”
CAT16 with 3948K (invalid) on the right … image straight after open on the left (scene-referred, modern color)
“detect from image edges” works with this image:
The problem is not the algorithm yielding a weird cast , the thread is about turning the image completely black or blue… like unrecognizable.
I hardly use denoise and I do have the issue , so denoising with wavelets or not has nothing to do with it in my mind.
The suspicion was 'nvidia on windows ’ but priort seems to rule that out (did you try resetting color calibration And then retrying one of the auto detect options ?).
Could still be Nvidia windows related , because so far the people describing the issue are on a gtx1000 series or newer .priort’s 700 series card is quite a difference architecture .
And also no issue with my 3060Ti
@jorismak and @priort The issues happens to me with OpenCL turned off (CPU path).
Todd, can you pastebin a pacman -Qe from your build environment?
By the way, I’m reading channelmixerrgb.c trying to understand how the ai works. This comment in row 1181 is hilarious:
// note : it will only be luck if I didn't mess-up the computation somewhereWill do. Also I have seen log output after crashes and from the command line but if I do -d all and run a GUI instance where is the output saved… I know I should know…
priort saying no issue with his 3060ti means my theory is already broken.
Your message that it also happens with opencl turned off means it’s completely down the train 
.
Bit flabbergasted now though. It would hint at a problem in gtk / gdk internals of the Windows port… but since some Windows people are not having this issue while others do… 
. Maybe it’s a nasty combination of packages in my msys2 installation.