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

[Gilles Caulier]

On Tuesday 26 September 2006 19:32, Colin Guthrie wrote:
> 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).

I'm agree with you about this point. Some plugins change metadata from file, 
like JPEGLossLess and GPSSync. A virtual method is missing to inform host 
about that. This point is very important for digikam, since we using sidebar 
to show metadata (instead dialog), because the sidebar content is not updated 
after a plugins session.

>
> This structure keeps the API clean.

But do not solve all cases, especially if the user want to tag GPS info to a 
picture file format witch non support Exif !

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

yes (:=))

>
> 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-apido
>cs/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.
>

Perhaps a more metadata API will be better, but it's require a lots of change 
in libkipi. This can be dangerous to do it and require a lots of test with 
all hosts.

Gilles