[KPhotoAlbum] Auxiliary files, again
johannes at zarl-zierl.at
Sat Apr 6 19:43:39 CEST 2019
Am Donnerstag, 4. April 2019, 02:34:08 CEST schrieb Robert Krawitz:
> > I think as you describe the use-case, stacks are really an
> > orthogonal concept.
> Well, the idea is that they're associated with one (or a group of)
> photos. The way I use stacks, at any rate, is to stack all images
> that are the same shot or a direct derivative; in that light, the
> sidecar files are similar.
> > Just checking with one .xmp I picked randomly, it seems that the
> > filename is stored there. I don't know whether this is required for
> > xmp files, and how it is for different sidecar formats.
> It's not for .pp3 files (just checked).
Thanks for checking...
> Perhaps, but I want to make sure that any copy/import/export operation
> has the ability to include sidecar files of the user's definition
> (there's no reason they have to be restricted to specific known
> varieties; darktable, hugin, and rawtherapee are surely not the only
> things that have sidecar metadata). That would argue for them to be
> first class objects. They aren't actually images, to be sure, but
> they are representations of images.
So this begs the questions:
1. What kind of sidecar files are there, and which ones do we want to support?
Note: Most file types would be 1:n, though with hugin or other panorama files
we would have a n:m relation
2. Does a sidecar inherit the tagging data of the associated image(s) or does
it need separate tags?
3. I guess that just displaying a list of sidecar files is not enough to work
with them in a meaningful way? If not, I guess we need to allow for some kind
of extension mechanism to render and interact with the files.
I can see your point and that this can be a big improvement for kphotoalbum,
albeit one that is not trivial to implement properly.
I do like to continue this discussion, but I guess it's fair to add a
My gut reaction would be "can we postpone this until we have a testing suite",
but that would be unfair to you. Right now, for me the biggest priority is to
reduce our technical debt and get a clean boundary between UI and non-UI code.
More information about the KPhotoAlbum