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