[Kde-imaging] RFC: (FAO Gilles) next kipi & co. generation

[Colin Guthrie]

Firstly sorry for the long email, but I hope I've made myself clearer now :)


Gilles Caulier wrote:
> Well, the problem is simple : a kipi host store in a database some metadata 
> informations about photograph to performs search. For performance reasons, 
> this is mandatory : try to search a metadata using only informations stored 
> in picture files, and you can take a coffee (:=)))

Absolutely! I wasn't disputing this and know 100% why databases cache is
needed/desired etc.

> Second points, is about metadata an pictures format : not all file formats 
> support metadata ! Exif (the most important format used in photography) is 
> supported by TIFF, JPEG, and PNG only, but not by TGA, BMP, JPEG2000, EXR, 
> GIMP, etc.

Yes, this was why I said I only wanted to use Exif as an example in my
original email.

I wasn't trying to debate either point in my original mail, so I'll try
to explain again my concerns and see if you agree :)

The issue I have is that the API is being changed to suit a very
specific need of one plugin. This goes against the whole point of having
a generic plugin API IMO.

Originally I was suggesting that the Kipi Plugin be responsible for
writing new Metadata into the file as appropriate for it's need (i.e.
nothing to do with any API to a host application). It would then have a
generic API call to tell the host application to re-read a given image's
metadata from the image file itself. This way there is no specific calls
required in the API, just one generic one.

An example:

1. GPS Kipi Plugin is working with an Image.
2. The user set's location co-ordinates by clicking on a map.
3. The Plugin updates the Images' Metadata on disk (no Host App
communication).
4. The Plugin then tells the Host App to re-read Metadata for Image (or
in other words, invalidates the Host Apps cache for that file).

This structure keeps the API clean.

But it does have disadvantages:
* Kipi plugin must be aware for how to read/write file metadata for
different formats. If a file format does not support metadata then
things break (== bad!).

So let me change my original stance slightly (see below).

> The problem that i have describe about GPS info is similar than image comments 
> or date. In libkipi, we have methods to changes in host the image comments 
> and date ! With digiKam, comments and date are stored in database, and if 
> supported, into the file format, like Exif, and IPTC. 

OK, I appreciate that some file formats do not support metadata directly
and in that case, the Host App is the sole source of metadata.

Expanding this out, saying that the host application can read/write file
metadata when supported, it makes sense to use the host app to alter the
metadata 100%.

BUT, I think my argument still stands in that we are still writing very
specific functions into the API that will cause future problems (ABI
changes etc.)

Could the reading/writing of metadata from the Host Application be
abstracted into  a few standard calls and perhaps use #defines to
determin the data.

e.g.
hostapp->readMetadata(image, KIPI_IMAGE_METADATA_ORIENTATION);
hostapp->writeMetadata(image, KIPI_IMAGE_METADATA_LONGDITUDE, "117.28384");
etc.

This would allow for a sandard API and applications?

I am perhaps completely misunderstanding you in the first place and
perhaps all this metadata is already handled via the
attribute/addAttributes calls in a completely generic way?

e.g. via:
http://developer.kde.org/documentation/library/3.5-api/extragear-libs-apidocs/libkipi/html/classKIPI_1_1ImageInfo.html#_details

(although I belive that attributes were originally designed to deal with
Gwenview categories(?) so I'm not sure if this is the case)

Certainly ImageInfo has specific method for angle, time, description
etc. which would seem to imply that you were referring to adding new
methods.





Anyway, ignoring all the above, I'll move on to my second, (more
important) point.

You referred to a method you've added to Digikam to make Tags avaialble
in a similar way to Albums - great! :)

But you also said:
> In libkipi, there is an important wish about to give a tree folders list if 
> the host support album == folder. I think we must fixed this point for the 
> next release.

This implies that the Tag bases access and the Album based access will
differ and will require Kipi Plugin authors to code them differently.

I would sugges that the folder of an album (or ImageCollection in class
name terms) should be irrelevent to Kipi Authors. I just want a
Hierarchy, but I shouldn't have to look at folder paths for that
information, it shoudl come from the Host Application. That way I can
see a heirarchical view of Tags and Sub-Tags in my plugin too!

So I would suggest that all mention of folders etc. be removed
completely from the API.
e.g.
http://developer.kde.org/documentation/library/3.5-api/extragear-libs-apidocs/libkipi/html/classKIPI_1_1ImageCollection.html
remove the methods isDirectory(), path(), uploadPath(), uploadRoot()
etc. and find a better way of doing this without relying on fixed paths.

I'm not bothered really about this, but it just seems to me that the
whole point in a generic API like Kipi is to keep things nicely
abstracted. By implementing methods like isDirectory() etc. we are
exposing a lot of the underlying implementation and actually putting
restrictions on how host applications have to be structured in order to
take advantage of certain plugins' functionality.



One of the reasons I began thinking down this line is that I want to
implement Syncronisation for the Gallery Plugin. To do this I need to
store information about ImageCollections (e.g. which remote gallery to
synchronise to) and ImageInfos (e.g. exclusions for specific images
inside ImageCollections).

Now, ImageCollections to not necessarily represent a fixed Album or Tag
view, they could just be a random selection of images the user has
chosen I belive? (certainly the implementation of ImageCollection allows
this). Obviously I wouldn't want to store settings for a random,
one-time selection of images, so I would suggest something like
ImageCollection::isPermanent() which defines whether an ImageCollection
is permanent or not (e.g. and Album, Tag, or Advanced Search result
etc.). An ImageCollection CAN be permanent, and NOT support upload (e.g.
Tags and Saved Searches)

For permanent ImageCollections, I would like the host app to provide the
Kipi plugin with a KConfig style interface such that the Plugin can
store generic configureation settings about that collection. Likewise
ImageInfo would also have a KConfig style interface that applies to
individual images.

The host application would be responsible for ensuring the config data
is written to disk/db properly.

This would allow e.g. the Flickr, Gallery and iPod plugins to work much
better and provide Synchronisation interfaces for not just raw albums,
but also saved searches, Tags etc. while remembering the settings from
one session to another - this will eventually allow me to e.g. Download
comments made by others about your pictures on Flickr/Gallery and
display them in Digikam, or automatically Sync a set of Tags or result
of a search to a remote album (all very desirable features!).



I hope I've made myself clearer in this post. I apologise if i've
misinterpreted the current API in some way or if I'm looking at old docs.