You need to adjust nind_denoise = and nind_denoise_param = in dt_nind_denoise.ini according to your paths. Something like this (using the same paths when you tested denoise_image.py manually):
nind_denoise = python "C:\Darktable_NIND\nind-denoise\src\nind_denoise\denoise_image.py"
nind_denoise_params = --network UtNet --model_path "C:\Darktable_NIND\nind-denoise\models\generator_650.pt"
Makin’ progress, it finished! The photo is denoised and processed… Thanks for helping me make it run.
There are problems though – The exposure (as I saw someone mention) is probably applied twice as the image is quite overexposed. There are also some glitches in the image:
Also, the sharpening seems over-done compared to my original render (I think I forgot to remove it from the .xmp, oops!) This render (the noise reduction and sharpening) reminds me of my phone’s night-mode kinda look. But considering the model had so little training data, I think it did a very good job
be sure to compress the history before running the script. Multiple instances of a module is unpredictable when we mess with the XMP outside darktable.
If you prefer using DT sharpening (over RL-deblur), you can run the script with --no-rldeblur flag, or disable gmic permanently by commenting out gmic in dt_nind_denoise.ini
For images too dark that you push at least +4EV in darktable, try running the script in night mode (with -n or --nightmode flag) and see if you can get better result. It basically shifts exposure and toneequal to 1st-stage to have a “normalized brightness” image before feeding to nind-denoise.
P.S. - the denoise at the top is disabled, so it’s not actually using it
EDIT:
s1 image looks already overexposed, just low contrast
can you share your XMP (and if possible, the RAW file)?
I’ll look for a different raw where the location is not obvious, I’ll test it and share it here.
DSC_0339.NEF.xmp (27.3 KB)
DSC_0339.NEF (24.9 MB)
This file is licensed Creative Commons, By-Attribution, Share-Alike.
There you go. This is what I get:
The burning artifacts seem to be in the areas of some channel or gamut clipping… But not sure about it
It’s likely “input color profile” issue, I’ve updated the code to move “colorin” right next to “demosaic”. Your NEF and XMP file works well on my darktable 5.3 now, pushed the fix to git.
Please copy your existing dt_nind_denoise.ini to somewhere else (just in case we lose your settings) and do a git pull origin
In dt_nind_denoise.ini, to specify the paths on Windows, please use either forward-slash /, or double-backslash \\, instead of single-backslash \. For example:
darktable = "C:/Program Files/darktable/bin/darktable-cli.exe"
or
darktable = "C:\\Program Files\\darktable\\bin\\darktable-cli.exe"
When I run the script with the dt_nind_denoise.example.ini from the git pull, it throws an error:
Error reading C:\Darktable_NIND\nind-denoise\src\darktable\dt_nind_denoise.ini
renaming it to dt_nind_denoise.ini, as it was before, gives me this error:
PS C:\Darktable_NIND> python .\nind-denoise\src\darktable\dt_nind_denoise.py -d "DSC_0339.NEF"
Traceback (most recent call last):
File "C:\Darktable_NIND\nind-denoise\src\darktable\dt_nind_denoise.py", line 425, in <module>
main(sys.argv[1:])
File "C:\Darktable_NIND\nind-denoise\src\darktable\dt_nind_denoise.py", line 149, in main
cmd_darktable = config['command']['darktable'].strip()
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.12_3.12.2800.0_x64__qbz5n2kfra8p0\Lib\configparser.py", line 1224, in __getitem__
raise KeyError(key)
KeyError: 'darktable'
Oops, I meant to write this in that example.ini file (too tired after 6 hours straight of debugging a new related issue 
)
# for Windows: darktable = "C:/Program Files/darktable/bin/darktable-cli.exe"
If you’re not sure what to edit your dt_nind_denoise.ini file, just paste the whole file here and I’ll edit accordingly.
Okay, here’s my .ini file:
[command]
# path to darktable-cli
; darktable = /opt/darktable/bin/darktable-cli
; for Windows:
nind_denoise = "C:\\Program Files\\darktable\\bin\\darktable-cli.exe"
#path to gmic
; gmic = /usr/bin/gmic
gmic = "C:\\Users\\---\\Documents\\Programy\\gmic-3.5.5-cli-win64\\gmic.exe"
# command to invoke nind-denoise
;nind_denoise = export 'PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:512'; /home/noname/python_envs/nind_denoise/bin/python3 /home/noname/nind-denoise/src/nind_denoise/denoise_image.py
python "C:\\Darktable_NIND\\nind-denoise\\src\\nind_denoise\\denoise_image.py"
# path and network type of the model
; nind_denoise_params = --network UtNet --model_path "/home/noname/nind-denoise/models/generator_650.pt"
nind_denoise_params = --network UtNet --model_path "C:\\Darktable_NIND\\nind-denoise\\models\\generator_650.pt"
Trying with forward-slash first (instead of double-backslash) as that can prevents many path problem.
[command]
# path to darktable-cli
darktable = "C:/Program Files/darktable/bin/darktable-cli.exe"
# path to gmic
gmic = "C:/Users/---/Documents/Programy/gmic-3.5.5-cli-win64/gmic.exe"
# command to invoke nind-denoise
nind_denoise = python "C:/Darktable_NIND/nind-denoise/src/nind_denoise/denoise_image.py"
# path and network type of the model
nind_denoise_params = --network UtNet --model_path "C:/Darktable_NIND/nind-denoise/models/generator_650.pt"
try running in debug mode (with -d flag), it’ll keep the intermediate TIFF files instead of deleting them (in the same folder as the RAW file). You can then inspect each and confirm at which stage the artifacts came in.
You can also import the TIFF files into darktable, and load the corresponding .s1.xmp and .s2.xmp files manually to see what could be the cause.
The flow is:
Also, which version is your darktable?
Alright, will do.
5.2.0
The artifacts come in the nind denoising stage, i.e. DSC_0339_s1_denoised.tiff is the first file with artifacts.
If the 1st-stage export before nind-denoise (DSC_0339_s1.tiff) doesn’t have artifacts but the denoised TIFF does, then it’s something with nind-denoise. But it could be that the 1st-stage TIFF (before denoise) has clipped data that affect nind-denoise. Maybe try upgrading to darktable 5.3 is possible.
The TIFF32 file (DSC_0339_s1.tiff before denoise) is quite large so I don’t know if you can find a way to share it temporarily (please don’t post it here, the mods will kill us both).
I ran mine again using CPU instead of GPU and it still came out clean. I checked out and recompiled darktable to release-5.2.0 tag, still clean. I’m using the exact same XMP file that you posted earlier (maybe download the XMP file you share from here and try again to be on the safe side).
I assume you’re using this model?
https://drive.google.com/drive/folders/1P0UsenafuSKOmOzUXqRg20-Q6j2eoTXe
Can you try a few other RAW files and see if there’s a pattern on what could be the cause?
Yes, this is the model I use.
Yes that’d be a BAD idea to upload a 200MB tif 
Also, my bad, the tif before denoising is already glitchy, I was only judging the thumbnail, which is wildly different. Anyways, here’s the DSC_0339_s1.tif as viewed using XNView MP:
There’s a 5.3.0 .exe on Github, I could perhaps install it alongside 5.2.0, but I have never tried it, maybe it will work fine
