[KPhotoAlbum] Auxiliary files, again

[Robert Krawitz]

On Wed, 3 Apr 2019 23:56:03 +0200, Johannes Zarl-Zierl wrote:
> Hi Robert,
>
> Am Dienstag, 2. April 2019, 02:08:42 CEST schrieb Robert Krawitz:
>> What I'd like to do is stack auxiliary, non-image files with real
>> images, using autostack rules like the existing ones for autostacking
>> imags.  This sounds straightforward enough, but I can think of
>> difficulties:
>> 
>> * If a stack is broken by having one or more of its images removed,
>>   what happens to the auxiliary files?  Do they automatically stay
>>   stacked with one or another of the images, do they get dropped, or
>>   what?
>
> 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.

>> * Checksums may not be sufficient to distinguish between auxiliary
>>   files.  The odds against two auxiliary files having identical
>>   contact might not be that high, particularly if the filename is not
>>   stored in the auxiliary file.
>
> 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).

>> I'm sure there are other issues I haven't reached yet, but
>> nevertheless, this kind of functionality would be extremely useful.
>
> How about taking a different approach than the darktable "a sidecar
> file is an image" one?  One possibility would be to have the base
> image and to add the sidecar files as sub-images. That way, we could
> do away with checksumming for sidecar files, both eliminating the
> possible duplicate problem and avoiding incorrect checksums all the
> time because sidecar files are more likely to be modified at some
> point.  How to present this image-group in the UI is a different
> question, though.

I think we have the same logical view of the situation, but are
looking at the details a bit differently (perhaps we use kpa
differently?).  Regardless, this way makes sense.

> Maybe we could even go further with this approach and omit the
> sidecar files from the database altogether by checking for sidecar
> files on demand...

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.
-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton