Works like a charm so far!
Embedded lens corrections and sigmoid and X-Trans highlight reconstruction are fantastic additions to my editing!
I now have exported multiple times the same photo. I noticed that even i export the same photo I see different behavior; My Task manager at the first attempt seems to actually use the GPU. ; doing it repeatedly seems sometimes to turn off the GPU; export then gets slow. I am left with the message working… When shutting down the program, it does not always completely hut down, so I have to kill and restart. It seems much less of a problem when I export from lighttable view. From there I can export multiple images in a decent time (34 images in 10 minutes). from darkroom the operation is longer. I will need to check the manual how to activate a log, and report back in a few days. Need to do some urgent work right now.
I have not noticed any issues exporting… Win11 Nvidia GPU
No issues here, works fine: Win 10 + GPU NVIDIA GTX 1060, Win11 (Surface)
Thanks for your work @wpferguson.
You are the second person reporting a similar issue. A log of -d opencl and -d tiling might be helpful to understand what’s going on. Do you have the opencl tunning on?
There may be a problem with snapshots. I work an image to get a look that I like. I then take a snapshot. I want to then try editing the image again from scratch so I clear the history. But when I clear the history the snapshot also reverts to how the image opens by default. I want the snapshot to remember my first editing attempt. I believe this behavior (misbehavior) is new the DT as I am sure in the past I have used snapshots in a similar way it it remembered and showed my first attempt.
1 Like
darktable-log-12-8.txt (37.6 KB)
I attached a log file for darktable getting stuck; I am running on windows11; Files I am processing are pentax-dng files
Not that it’s helpful but I found this Pentax file in my Playraw folder… I build DT last night so went from 4.1 + 1156 now to +1185… I have no issue on Win 11 with an Nvidida card to export this file… I have profiled denoise, CA, I added 5x D&S each with 12 iterations and i added Laplacian HLR at 512 radius and 32 iterations… The image was ugly in the end and it wasn’t exactly a fast export but no issues…
For sure I will try to report this tomorrow… I tested it and compressing the history stack at any positions clears the snapshots…
I just found that this was reported in Nov… but its not a bug. It is the way it has to be because dynamic snapshots reference the history stack when a snapshot is created… Will likely confuse people and if you are editing against a reference image then you are going to need to take the snapshot and then make a duplicate image that you can play with and then you can compress if you want and this will not impact the snapshot as it is generated on the history stack of the original image…bottom line if the snapshots come from the image you are currently working on and you compress the history stack you will loose it…
Bummer that it works this way, but if I have to do a duplicate image I will have to. Thanks for your response
works as designed: see comments in Compress history stack erase snapshots · Issue #12766 · darktable-org/darktable · GitHub
I learned from earlier versions of Darktable, that you’d better restart darktable anytime you change a style, preset, or keyboard shortcut, as they only get saved at shutdown, but will get lost if darktable crashes. And from painful experience, it will crash.
But so far, with this version, it has been rock-solid.
Well as long as you walk through your xmp and leave it intact and don’t compress you will be fine so I guess it depends on that. If you settle on an edit and want to compress I guess you don’t need the snapshots anymore anyway unless you want to keep it for the next image and then you would have to leave the stack alone.
I tested the latest nightly build today …7f06.zip. Exported the same pictures from lighttable as before and did not see any “freezing” anymore. However, when watching my Task manager I also did not see any GPU activity. When using darkroom, i get export, however, the software freezes; After double clicking in the selector pane the same or any other picture I see “working…” Closing down, does not shut down completely; I need to kill darktable in the taskmanager to restart. In darkroom, however, I also see GPU activity.
darktable-log-f706-built.txt (10.4 KB)
IT also doe not seem to be linked to a specific file (photo). If I use files from other folks downloaded from the “processing” section; tried nikon (NEF) and canon (cr2) files I seee xactly the same behavior.
Thanks for the log file.
Can you do the same steps you did but this time turn off the OpenCL tunning (set to nothing)?
Turning off OpenCL, does not produce any freeze. I did not stop times, but it felt like it’s actually a little bit faster than with OpenCl enabled.
darktable-log-without-OpenCL.txt (4.5 KB)
But what about OpenCL on, but tunning set to nothing?
Ive been trying to recreate this issue on Windows and I cant. I’ve set my resources to mini to force tiling, adjusted to memory/transfer tunning on, and adjusted the openCL mandaroty timeout to 10; but I still cant reproduce. I’ve been using my compiled version, but current URCT.
So far Ive seen 3 reports and they seem to have in common that 1) D&S fails during a tiling and 2) Transfer tuning in ON. After the failure then the GPU is no longer use with a process running in the background.
If there is an issue, we will discover it with more users using 4.2 in windows.
If you tell me which parameter to change. I’ll do, sure, however, when selecting OpenCl I did have set tune OpenCl performance for memory and transfer. Should I restrict that?
IF you give me some guidance what other options to try (command line or otherwise), I am happy to do. we are having a rainy day here, not much to do today