I actually tried again (it’s been ages and I just don’t touch those auto-detect options, because they never gave good results for me). It works fine now on a .ORF file (although both options make the colors way too warm).
But if I try them on the DNG I normally use (of the same file), the first ‘ai’ seems to work, but gives a completely different color cast (very wrong, quite blue / green), and the second option gives a complete black screen.
If I change the white balance from ‘camera reference’ to ‘daylight’ (not that much difference visibly) and then try the auto detect again, the first ‘ai’ option now suddenly gives a way too warm result (just as with the source ORF file), but the second ‘ai’ option still gives a black screen.
With the ‘black screen’ syndrome, the hue and chroma sliders show no value, so they appear to have a value way outside the normal range. The moment I double-click on both of them (so they show a value again) the image is back.
Messing with the white balance module can make one of the ai options suddenly ‘work or not’, but also affects the outcome of it (??). And messing with the black-correction in the exposure module also seems to effect it.
But this is all with a DNG file, which has is values rewritten to be between 0 and 65535 instead of original black/white values of the RAW file.
As I said, the original RAW file works fine. Maybe it isn’t Windows related at all, but has to do with the black/white levels and white-balance presets of the file, and those can differ camera to camera / shot to shot.
It seems to me that whatever the ai function is doing yields a value for the hue degree and temperature that the slides can’t handle. The history shows NaN for 3 values (NaN = not a number).
For me the issue happens more often in the edges (borders) detection. I started to read thru the code but I’m not sure if I’m looking at the right section in the 4k rows. The math seems complex (radians to degrees and a lot of division).
The DNG is a linear dng, written by another program, so already demosaic’d / denoised / sharpened / lens corrected. And although the ‘color space’ isn’t altered (no profile or matrix applied yet), the data is scaled, so black level is always 0 and white level is always 65535.
‘Comparing data’ seems a bit difficult in this case.
Since it does happen in other files that are true raw files, I have a feeling with the NaN notices that others have, something isn’t just properly clipped in the calculations.
Thanks for sending the build config. I checked and we both match except that you have mingw-w64-x86_64-portmidi 1~2.0.3-1 that I dont use. I also have the UCRT packages since I’m building on UCRT now.