|This panel allows manipulating the history stack (development) of images. For each image, development is written in a sidecar file (.xmp), and is fully non-destructive.|
Copy the history stack of the selected image. You will be prompted for which items are to be include. If more than one image is selected, the history stack is taken from the image that has been selected first.
Copy the complete history stack of the first selected image; all items will be included. If more than one image is selected, the history stack is taken from the image that has been selected first.
Physically delete the history stack of the selected images. Beware, this action can not be undone!
Paste a previously copied history stack onto all selected images. You will be prompted for which items to include. This button is greyed out, until a history stack is copied from another image.
Paste all previously copied items of a history stack onto all selected images. This button is greyed out, until a history stack is copied from another image.
This setting defines how a new history stack behaves when pasted on an image that already has a history stack. In simple terms the “overwrite” mode deletes the previous history stack, whereas “append” will concatenate the two history stacks.
A copied history stack can have multiple entries of the same module either with the same name (see Section 3.3.3, “History stack”) or with different names (see Section 3.2.4, “Multiple instances”) and pasting behaves differently depending on the mode setting. On append mode, modules from the source image will be merged into the destination image in the following way: for each copied module of the source image, if there is a module in the destination image with the same name it will replace it. If there is not a such module, a new instance will be created. In both cases the instance is placed on top of the history stack. The “copy all”/“paste all” action with this mode will only copy the respective last instance of all modules with the same name to the source image.
In overwrite mode the behavior is the same except that the history of the destination image is deleted before the paste operation. The “copy all”/“paste all” action with this mode works differently; it will make an exact duplicate of the source image history to the destination image with all instances of all names of the modules.
Note: if you use “overwrite” mode to paste history stack entries to the images that wasn't opened in darkroom previously, i.e. the automatic module presets weren't already applied to the image, next time you open said image in darkroom, the automatic presets will be applied to the image. So it may seem as if the “overwrite” mode did not actually override the existing history stack, but in fact it did override it, and the rest was added later.
Caution: only in “append” mode you keep the option to later reconstruct your existing history stack whereas in “overwrite” mode your previous edit gets irrevocably lost. Beware, the setting of this parameter remains effective when you quit darktable.
Opens a dialog box to select an XMP file, thus loading a history stack that you can paste on images.
Files that were exported by darktable typically contain the full history stack if the file format supports embedded metadata (see Section 2.3.12, “Export selected” about this feature and its limitations). You can load an exported image as a sidecar file in the same way as you do with an XMP file. This feature allows you to recover all parameter settings in case you have accidentally lost or overwritten the XMP file. All you need is the source image, typically a raw, and the exported file.
Write XMP sidecar files for all selected images. The filename is generated by appending “.xmp” to the name of the underlying input file.
By default darktable generates and updates sidecar files automatically whenever you work on an image and change the history stack. You can disable automatic sidecar file generation in the preferences dialog (see Section 8.2, “Core options”). However, this is not recommended.