I’ve been using Darktable along with Digikam and XnViewMP under KDE linux for a couple of years. I usually open Darktable with a specific image file from one of these apps via the “Open With…” option. This has historically worked beautifully but I’v3e recently had issues, mostly with TIFF files, but also some others.
When I try to open a TIF image in this way from Digikam or XnViewMP, Dark Table opens, but freezes when it tries to present the image in the Darkroom window.
This also happens when using the terminal command, as in “darktable filename.tif”.
This also happens when opening an image from Dolphin file manager using “Open With…”
When I open DarkTable directly after this happens, the file(s) I tried to open are in the light table area (they were not imported prior to this.)
DarkTable opens these images perfectly when I open the them manually from within the DarkTable app using “Import…Image”.
My TIFF are all 8-bit, ZIP compressed (deflate), and use the “TIF” extension (all lower case only). I’ve tried changing the extension to TIFF (lower case) with no change in DarkTable response.
This also occasionally (but less often) hapens with other formats, so not exclusive to TIFF.
This doesn’t happen when DarkTable is already open and an instance is running on the desktop; only when it is called from the “Open With…” dialogs and has to open a new instance.
I am at a loss as to what might be the issue.
System Specs:
OS: KDE Neon 20.04 focal Kernel: x86_64 Linux 5.4.0-47-generic DE: KDE 5.74.0 / Plasma 5.19.5 CPU: AMD Ryzen 7 2700X Eight-Core @ 16x 3.7GHz GPU: Radeon RX 570 Series (POLARIS10, DRM 3.35.0, 5.4.0-47-generic, LLVM 10.0.0) RAM: 2432MiB / 32092MiB
DarkTable specs:
Version: 3.0.1
compile options:
bit depth is 64 bit
normal build
SSE2 optimized codepath enabled
OpenMP support enabled
OpenCL support enabled
Lua support enabled, API version 5.0.2
Colord support enabled
gPhoto2 support enabled
GraphicsMagick support enabled
OpenEXR support enabled
It’s not “out of date” as far as Linux repositories are concerned. v.3.0.1 is the current version in Ubuntu Focal repos. I’ll check on a manual upgrade or potentially install from snap, which is running 3.2.1. That said, I’d be surprised if a minor upgrade fixes an issue like this, unless DarkTable was known to have issues like this before the upgrade. I’ve been running it for a couple of years now without this problem, so I have to wonder if it isn’t a config issue or something…
Using darktable 3.2.1 I can replicate this behaviour (or at least the parts I can test).
Using GIMP, XnViewMP or, from a terminal, darktable image_name.extension will freeze darktable. This does not seem to be tif related (tried with rw2 and nef RAW files).
Darktable opens in darkroom view and says (bottom) working… and loading image image_name.extension and that is all she wrote.
compile options:
bit depth is 64 bit
normal build
SSE2 optimized codepath enabled
OpenMP support enabled
OpenCL support enabled
Lua support enabled, API version 6.0.0
Colord support enabled
gPhoto2 support enabled
GraphicsMagick support enabled
ImageMagick support disabled
OpenEXR support enabled
EDIT: This does not happen if I do the same and use rawtherapee. So it looks like this is darktable related.
Noted, but my point stands… I did try the snap, but there are too many issues, even with additinal permissions (as you noted). As @Jade_NL subsequently points out, this behavior is not resolved by using 3.2.1… Bug?
I’ll have to test some more tomorrow, but this may have solved the issue with XnViewMP, which allows me to manually edit the command line and switches. I’m not sure how to do that with Digikam and Dolphin, though. The DT options do not allow me to disable OpenCL (option is greyed out). Is there another way to tell DT to always run with OpenCL disabled? Config edit, maybe? Found it, I think… edited line in .config/darktable/darktablerc to change
OpenCL=TRUE
to
OpenCL=FALSE
Opened DT and config indicates OpenCL is not available. Will test with Digikam tomorrow and see how that goes!
Understood, but it reports as “support enabled” which means it is running the OpenCL process at every start. My goal was to disable the OpenCL script at startup. When I first looked at the setting in DT config, it was greyed out, but said “support enabled”. After editing the darktablerc file, it nows shows as “not available”.
Update your lua scripts to the latest version and see if the problem persists.
In mid August I added a patch to all the scripts that create a module that checked to ensure the view was lighttable before trying to create the module, which was in response to this situation, or a situation similar.