Potential dangers of accidentally deleting history stack in the "load sidecar file" function
Use cases with potential problems
I don't know whether to call this a feature request or a bug...
I notice (at least on my system? darktable v1.4.2 on 64-bit Fedora 20) the .xmp sidecar files associated with exported images contain metadata only, they do not contain the history stack; only the sidecars for RAW images contain history data. So when you click the "load sidecar file" button, if you choose the .xmp file for an exported image (whose history information will be empty), it will delete any existing history stacks for the currently selected images in lighttable view.
Another possible point of confusion: In the history stack panel you might normally click "copy" and then "paste," but the "load sidecar file" button copies and pastes all at once. The tooltip for this button says as much, but new users might miss this if they aren't paying attention, since the "load sidecar" and "write sidecar" buttons sound similar to "copy" and "paste."
I'm about to send a pull request on GitHub which will add some warnings about these potential pitfalls to the user manual. However, better than a warning might be to disallow loading sidecar files for exported images in particular, or for any sidecar files which do not actually contain a proper history stack.
Or, we could make it so the history stack is saved to the sidecars for exported images. This would perhaps be a little redundant if the history stack is already saved to RAW image sidecars, and there's already a way to save multiple development versions -- but redundancy is safer, and I imagine the extra disk space used would be trivial.
The problem of loading an empty history stack from a sidecar file could also probably be avoided if there were a popup confirming the history stack items being copied when you click "load sidecar file" before the loaded history is applied to selected images.
#2 Updated by Tobias Ellinghaus about 5 years ago
- % Done changed from 0 to 20
- Status changed from New to Incomplete
I have no idea what you are talking about. Exported images don't have a sidecar file at all, not even one that is missing the history stack. And copy&paste don't operate on sidecars, while "load sidecar file" neither copies nor pastes.
#3 Updated by Andrew Toskin about 5 years ago
Exported images don't have a sidecar file at all
You're right that exported images don't have sidecars when you first export them. But they do get sidecars when you reimport the containing folder. Those new sidecars for the exported images contain metadata, but not history. The empty history information can then overwrite existing history stacks if you try to select the wrong .xmp files in the "load sidecar" function, either out of ignorance or just by accidentally clicking the wrong file.
copy&paste don't operate on sidecars
Wait, what? If the "copy" and "paste" functions don't get the history information from the RAW images' sidecars, then where does it come from? The database? I can see see darktable processing parameters in all my "photo.raw.xmp" files. Is that not the "history stack"?
"load sidecar file" neither copies nor pastes.
Um. Whatever you want to call it, the "load sidecar" function grabs image processing information from the .xmp file you select in the dialog, and then applies it to the images selected in lighttable view. As far as I can tell, that's the same as what the "copy" and "paste" buttons do, except "load sidecar file" can pull a sidecar from anywhere in the filesystem, not just the current lighttable collection, and it does both steps (grabbing and applying history information) all at once.