Problems and quirks with importing/exporting images via *.kim and some other things
Andreas Schleth
schleth_es at web.de
Fri Nov 14 13:17:39 GMT 2025
Hi everyone,
IMHO, the export/import feature via *.kim files could need some love. I
use this feature quite extensively and stumbled across several smaller
and larger problems. Some of that might be bugs, some might be usability
issues and some might just be p.e.b.k.a.c...
My main reason to use more than one database is backup. I do not need
every single image on off-site backup - only "valuable" images. Thus a
curated subset gets moved (via kim) to a separate database / folder tree
that is then backed up regularly.
kim feature:
1) There seems to be a size limit of ~4GB for *.kim files: I can easily
export larger *.kim files but on import KPA says "cannot open the file
for reading" (or so). Exporting the images with "copy next to kim file"
works, but that clutters my folder with 1000s of files.
ark also complains about the files (after renaming them to *.zip). Thus,
the size limit is most probably a feature of the zip library.
=> It would be nice if the size limit should be flagged before
exporting. Or the export stops when the limit comes close while giving
the option to split the export into multiple files.
2) After importing the images the files do not retain their original
time stamp (on the file system). This is OK for images but bad for
videos, as date/time gets updated from "exif" data - but in case of
videos from the file system time stamp. There is a corresponding bug
report: https://bugs.kde.org/show_bug.cgi?id=511440
I have a workaround, but this is quite clumsy: a script that reads the
(possibly corrected) timestamps from index.xml and updates the exif data
(also in videos), then a script to touch the files after import with the
timestamp from exif and finally "read exif data from file" in KPA. sigh!
2a) The timestamp formats in index.xml and *.kim are different. I there
a technical reason or is that just baggage from the past?
3) The default folder for reading the import file from: When I import
several *.kim files in one session, the file open dialog for the *.kim
file shows the last destination folder for the images, not the folder
the *.kim files reside in. It would be nice if KPA could remember where
the kim file came from and propose to read the next kim file from there.
4) The import dialog: the destination folder should be asked first,
because that is the one dialog, where you need to input something most
often.
5) The category matching on import: it would be nice to filter for
category items that do not match 1:1 existing items - to be able to
correct them. These are often overlooked because KPA automagically
selects "similar" existing items. This can cause quite a bit of trouble.
6) I would really like a method to synchronize categories/category items
between databases
one more thing:
7) When deleting files from disk (from the KPA dialog), the files get
added to the blocklist. But they shouldn't. Deleted from disk and
deleted from the database should be enough. I do not know how often I
had to clear the blocklist manually with the editor (thanks for a human
readable database!). This is a problem if I need to import the same
images again (e.g. after some corrections in the original database).
I understand, that the blocklist is necessary to delete files from the
database only.
Is any of this worth to add a feature request / bug on bugs.kde.org?
Cheers, Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kphotoalbum/attachments/20251114/81f03bf5/attachment.htm>
More information about the KPhotoAlbum
mailing list