Re: Non destructive editing and multiple XMP files for versioning?

I looked a little into the XMP versioning facility, and if I understand 
it correctly, the intention is to provide an "edit-trail" from original 
to final product, sort of like layers.

This would not really help much for multiple interpretations of the same 
shot, since that implies a "tree" of edit trails.

I think an XMP version edit-trail is built by each successive version 
pointing back to the previous.  That suggests one could construct a tree 
by having multiple XMP versions having the same predecessor.  This 
would, in turn, require image editing s/w such as DK to find a given 
original or version, and start such a fork in order to create a new 
interpretation.  While this could probably be done, it's complicated.  
If I were the developer, I'd choose to support multiple XMPs per 
original, and I would place the relative path to the original image into 
the first version to avoid some of the ambiguities of the current 
name-based scheme (as a side effect, this would also allow changing the 
XMP name to reflect the interpretation.)

Is this a correct understanding of XMP?  Has anyone thought of doing 
something like this?


On 10/18/2025 6:59 PM, George Koulomzin wrote:
> As digikam moves to non-destructive editing, I think it might be 
> worthwhile to revisit the 1-to-1 relationship of an original image 
> file with its xmp sidecar file.
>
> If a original image file, esp. a raw file, is thought of as a 
> "negative", and edited versions as interpretations (or "prints"), the 
> current versioning approach seems cumbersome.  All the different 
> versions of the original would be the same, as all edits creating an 
> interpretation are non-destructive.
>
> This suggests that an xmp file needs to refer to it's immutable 
> original, so that interpretations do not proliferate copies of the 
> original.  Such an approach poses questions of how such a reference 
> would survive changing path expressions, e.g. if an image or 
> collection is moved, etc.
>
> I would happily settle for a requirement that the xmp must be in the 
> same directory as the original, or that the xmp refer to the original 
> with a relative path expression.
>
> Is this something developers are thinking about?
>
-- 
George Koulomzin
7 Bridge Hill Lane,
PO Box 781
Bridgehampton, NY, 11932
(m) 914-393-6179
(h) 631-537-4956
[email protected]