Thanks, Kofa, for your suggestions. Re. Make sure 'don't use embedded preview JPEG but half-size raw' is disabled (so no raw processing happens on initial import):
By turning to the "darktable-generate-cache" binary to generate thumbnails "unattended" as suggested in the manual it seemed obvious that we had to disable the "half-size raw" option to allow for binary's thumbnails to be used when opening a folder for the first time in lighttable view. It is stated in the manual, that the binary creates the thumbnails directly in dt's thumbnail cache and -- only when the cache is exhausted -- stores them on disk (we have "disk backend thumbnail cache" enabled). When opening dt's lighttable view, they should be instantaneously available. At least on Windows this is not the case. The binary writes all thumbnails straight to file at "C:\Users\...\AppData\Local\Microsoft\Windows\INetCache\darktable\mipmaps-*". dt needs to build the cache from scratch when opening a folder in lighttable view. If this is conclusive, is it a Windows specific issue? Re. If you have lots of RAM and a modern CPU, you may want to raise 'number of background threads' Our initial screening/tagging usually happens "in the field". We rely on portable devices (Intel i5-6300, 2 cores, 4 logical processors, on-chip GPU). dt defaults to eight background threads. I would not know whether this is to many, just right, or not enough for our portable devices. Re. BTW, darktable can use the embedded JPG for full-screen preview - if an image has not been edited yet, this allows for quick review and culling. Switching to full-screen view works fine as soon as there is a thumbnail in lighttable view to start from. Our patience is put to the test by the time it takes until thumbnails appear. ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
