Each image in the current collection is represented by a thumbnail in the lighttable view and filmstrip module. A cache of the last recently used thumbnails is stored in a file on disk and loaded into memory at startup. The size of this cache can be adjusted in preferences > cpu/gpu/memory.
Thumbnails are created whenever an image is imported into darktable for the first time, after an image has been modified in the darkroom, or when revisiting an image whose thumbnail is no longer available.
When an image is imported into darktable for the first time darktable can either try to extract an embedded thumbnail from the input image (most raw files contain these, usually in JPEG format) or process the raw image itself using default settings. You can define how darktable obtains its thumbnails in preferences > lighttable.
Extracting an embedded thumbnail from the input image has the advantage of being very fast. However, these 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, at which point darktable replaces the lighttable’s thumbnail with its own internally processed version.
After importing a new film roll darktable automatically generates thumbnails for new images as they are needed. When importing a large set of new images, thumbnail generation can slow down navigation in the lighttable view. Alternatively you may terminate darktable and generate the thumbnail cache separately by running the darktable-generate-cache binary. This program will generate all missing thumbnails in one go.
As the thumbnail cache has a pre-defined maximum size it will eventually get filled up. If new thumbnails are subsequently added, old thumbnails are dropped from the cache. However, darktable will keep all thumbnails on disk if the corresponding disk backend option is activated in preferences > cpu/gpu/memory. Access to the thumbnails in this secondary cache is slower than the primary cache, but still much faster than reprocessing thumbnails from scratch. The size of the secondary cache is limited only by available disk space.
Thumbnails are never removed from the secondary cache. You can manually clean the secondary cache by recursively deleting all images in the
$HOME/.cache/darktable/mipmaps-xyz.d folder (where
xyz denotes an alphanumeric identifier of the cache). After clearing the secondary cache you can simply allow darktable to re-generate thumbnails as needed, or you can generate all thumbnails in one go with
If you choose not to activate the disk backend and select too small a cache size you may observe adverse effects: Continuous regeneration of thumbnails when you navigate your collection, flickering of thumbnail images, or darktable may even become unresponsive. A good choice of cache size is 512MB or higher (see memory for more information).
All thumbnails are fully color managed if the corresponding option is activated in preferences > 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 the color management section.
There are three main reasons that this could happen:
Missing Image File: darktable remembers all images ever imported, as long as they have not been removed from your database. If 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 using the selected images module before physically removing them from disk. Alternatively you may occasionally run the script
purge_non_existing_images.shfrom darktable’s toolset to clean-up your database.
Invalid Image Format: While the extension of an image may seem to be supported by darktable, its contents could be either an unsupported image format or a corrupt file.
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. See memory for more information.