Bug #9817

Unclearable presence of skulls (missing images)

Added by Walter de la Internet over 6 years ago. Updated over 6 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
git development version
hardware architecture:


The skulls that denote missing images never go away.

I am guessing that these derive from darktable remembering in its sqlite-based index that an image of a certain name once existed in a certain directory.

The only workaround I have found is moving the entire directory to a new name, which invalidates previous darktable caches.

There should be some other option here, such as:
(1) automatically invalidating the entry instead of showing a skull
(2) providing a button that reloads the current directory's entries from disk, clearing skulls by and invalidating previously cached ideas about which files have been present in the directory in the past

Personally I am keen on option #1 as I think the additional complexity of a skull and the type of approach to file management/workflow that it engenders is essentially needless and creates a barrier for inuitive use by new users. In short, it adds little functionality in many cases and confuses people.

The bug is made more serious by the fact that at least part of the development team seems keen on avoiding any file management within darktable, which then means that people do this manually, which naturally leads to skull growth conditions :)


#1 Updated by Tobias Ellinghaus over 6 years ago

  • % Done changed from 0 to 20
  • Status changed from New to Incomplete

What exactly is your problem here? Can't you just select the skull images and hit <del> to remove them?

#2 Updated by Walter de la Internet over 6 years ago

Well, sure. Manual processing might be option, but it's annoying. Maybe I didn't notice this 'delete' working on my (Macbook) keyboard as delete is mapped to backspace.

I still think there is a fundamental disconnection between index and reality, the management of which needs to be considered.

For example in one folder right now I am not seeing skulls but rather the assumedly related problem of loads of icons for images no longer present that, when clicked to get to darkroom view, trigger "image <imagename> is currently unavailable".

I think I once determined that this may be related to opening a folder without write permissions resulting in metadata being stored someplace else (~/.darktable or somewhere else dotfilesque / similar?)

Also available in: Atom PDF

Go to top