Problems and quirks with importing/exporting images via *.kim and some other things

[Johannes Zarl-Zierl]

I accidentally sent this mail off-list.

Hi Andreas,

Thanks for the comprehensive analysis.

> IMHO, the export/import feature via *.kim files could need some love.

Yes, very much so. The file format is largely unchanged since the beginnings of 
kphotoalbum, and AFAIK there were only slight UX tweaks on the GUI.

> 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.

When the .kim file format was created, 4GB was plenty ;-)

I just read up on this, and it seems that we could fix this by changing the file 
format:
https://en.wikipedia.org/wiki/ZIP_(file_format)#ZIP64

Could you please file this as a bug?

> 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'd say the best way forward is to fix the bug before the next release...

> 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!

+1 for your creativity

> 2a) The timestamp formats in index.xml and *.kim are different. I there
> a technical reason or is that just baggage from the past?

Very likely baggage from the past. The .kim import uses the same code for 
reading XML code as the index.xml file format.


> 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.

Sounds reasonable.

> 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.

You mean first after selecting the import file?


> 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.

Looking at this part of the UI:
I assume we can just filter out the special category Media Type and Folder.

How long does your list of categories get?
If it doesn't get too long, maybe an indicator for fuzzy matches would work 
just as well?

> 6) I would really like a method to synchronize categories/category items
> between databases

Sounds more like a feature in the next file version. Speaking of which, I'm 
inclined to keep the .kim file format frozen and add a new fileformat that does 
not share its code with the XML file reader instead.

> 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.

Good point.

> Is any of this worth to add a feature request / bug on bugs.kde.org?

Yes. Apart from maybe 2a, all of them are worthy of a bug/feature request.

Cheers,
  Johannes
-------------------------------------------------------------