Here’s the link to the latest weekly snapshot of darktable 4.1,https://drive.google.com/file/d/1hpeooq_Dotynyuj1Xb9H9lFu3tylEoIU/view?usp=share_link. The list of changes is at Comparing b0fb0b9c5..c0fa1b711 · darktable-org/darktable · GitHub
10 Likes
For those that spend their time in pixls.us and use darktable under windows, please try to make the effort to make this your daily normal version to use. This is in essence 4.2, but usage now will allow detecting bugs prior to release.
8 Likes
I am doing and I am seeing no bugs to report.
As reported earlier; after export the software gets stuck. I then do see …working… and no response. Windows 11. I tried both OpenCl on/off . Off means very slow; on means fairly ok work-flow, just problems exporting.
Can you provide more details? logfile?
FWIW, also on Windows 11 and no export issues with or without OpenCL.
Also might be usefull to provide raw and xmp sample files so developers have better chance to replicate the issue.
Tested on Windows 10 exporting from NEF file and no problems found here.
I’ve just installed this build, seems fine so far. With the last version, while I was trying out the different OpenCL tuning settings, I had a few odd long export times, and a couple of times it pretty matched what @Bernhard_Vogler described. I didn’t manage to pin it down to a particular setting though… it was almost more as if it was the repeated changing of settings that did it, but I will try it again with this build. Win11 here.
One more point, the new snapshot zooming is great, but if I use a snapshot of an OOC JPG, while editing the RAW, (.nef) the zoom does work but it doesn’t match… the jpg snapshot magnifies slower then the open file. Is this to be expected? Just wondering, no big deal for me. Edit: when I say slower, I don’t mean in time, rather in relation to amount of zoom compared the other.
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