Each image of the current collection is represented by a thumbnail in the lighttable view. darktable keeps a cache of the last recently used thumbnails in a file on disk and loads it into memory at startup. The size of this cache can be adjusted in the cpu / gpu / memory tab in preferences dialog (see Section 8.8, “Cpu / gpu / memory”).
Thumbnails get created whenever darktable imports an image for the first time, after an image has been modified in the darkroom, or when revisiting an “old” image whose thumbnail is no longer available.
When darktable imports an image for the first time, there are two possible sources from where to take a thumbnail. darktable can either try to extract an embedded thumbnail out of the input image – most raw files contain these kind of thumbnails generated by the camera – or process the image by itself using default settings. You can define how darktable gets its thumbnails in the lighttable tab in preferences dialog (see Section 8.3, “Lighttable”).
Extracting an embedded thumbnail from the input image has the advantage of being very fast. However, those thumbnails have been generated by the raw converter of the camera and do not represent darktable's “view” of that image. You will notice the difference as soon as you open the image in the darkroom mode, after which darktable replaces the embedded thumbnail with its own one.
After importing a new film roll darktable generates thumbnails for new images as they are
needed. In the case of a larger set of new images this slows down navigation in the
lighttable view as with each move new thumbnails might need to be produced. Alternatively
you may terminate darktable and start the
binary. This program will generate all missing thumbnails in one go. For more details see
Section 1.1.3, “
As the thumbnail cache file has a pre-defined maximum size it will eventually get filled up. Then if new thumbnails are added, old ones need to be dropped. However, darktable will keep all thumbnails on disk if the corresponding disk backend option is activated in the cpu / gpu / memory tab in preferences dialog (see Section 8.8, “Cpu / gpu / memory”). Access to the thumbnails in this secondary cache is slower than to the ones in the primary cache, but still much faster than reprocessing thumbnails from scratch. The size of the secondary cache is only limited by disk space.
Thumbnails never get dropped from the secondary cache. In case you want to clean it up you
can do so manually by deleting all images recursively in folder
denotes an alphanumeric identifier of the cache. Afterwards you let darktable re-generate
thumbnails as needed, or you generate all thumbnails in one go with
If you don't activate the disk backend and select a too small cache size you might observe adverse effects. Continuous regeneration of thumbnails whenever you move in your collection, flickering of thumbnail images, or even darktable becoming unresponsive are typical symptoms. A good choice of the cache size is 512MB or higher. Please mind that the inherent limits of 32-bit systems will force you to go for a much lower cache size (see Section 10.1, “darktable and memory” for more details on these limitations).
Starting with darktable 2.0 thumbnails are fully color managed if the corresponding option is activated in the lighttable tab in preferences dialog (see Section 8.3, “Lighttable”). Colors are rendered accurately on screen as long as your system is properly set up to hand over the right monitor profile to darktable. For more information on color management see Section 3.2.6, “Color management”.
There are three main reasons for this to happen.
One possible cause is that the input image has been renamed or physically deleted from
disk. darktable remembers all images ever imported, as long as they have not been removed
from your database. In case darktable wants to create a thumbnail but is not able to open
the input file, a skull is displayed instead. Users are advised to remove images from the
database (see Section 2.3.8, “Selected image(s)”) before physically
removing them from disk. Alternatively you may occasionally run the script
purge_non_existing_images.sh from darktable's toolset to clean-up
Another possible cause is sometimes darktable encounters an input image having an extension that seems valid for darktable but which has a file format that darktable does not support yet. darktable tries to process the image but is not able to get the job done.
The third possible cause for getting skulls is memory shortage: If darktable runs out of memory while generating a thumbnail, it will warn you and display a skull – this can happen if darktable is run with suboptimal settings, especially on a 32-bit system. Please consult Section 10.1, “darktable and memory” for more information.