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

[Gilles Caulier]

On Tuesday 26 September 2006 11:04, Colin Guthrie wrote:
> Hi,
>
> I don't want to be pushy, but I would really like some feedback on my
> response below. Angelo has already said he cannot really comment, but I
> would really value Gilles' opinion/thoughts on it as I am not familiar
> enough with the concepts to really know if I'm right or wrong.
>
> I just don't want to see the Kipi API becoming bloated with calls that
> are not needed/are too specific to any given case/plugin.

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 (:=)))

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.

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. 

Now that we have a GPS tool in kipi, i need a method to put the GPS info in 
database, like comments/date stuff are does.

Gilles

>
> Col.
>
> Colin Guthrie wrote:
> > Gilles Caulier wrote:
> >> Jain have added a new method to get virtual Tags folders like Physical
> >> folder from host database. i think he have used this methods into Flickr
> >> Plugin. In digiKam 0.9.0, the kipiinterface support this method and need
> >> to be tested indeep.
> >
> > snip.
> >
> >> 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.
> >>
> >> Aurelien, I'm sure you libkipi with album==folder. What do you think
> >> about?
> >
> > The above two points to me seem like they conflict and it would be
> > better to standardise.
> >
> > Personally I would prefer if the host application completely abstracted
> > the fact that and "album" can just be a folder on disk. IMO the plugin
> > should not know where to get an albums folder.
> >
> > If Albums and Tags are treated differently then it means that any kipi
> > plugin may have to handle them differently.
> >
> > To me it would make more sense to have the general concept of "Albums"
> > generically and perhaps have a type of album for specific handling e.g.
> > "Standard, Tag, Search" could all be Album Types.
> >
> > Now I may be overlooking something here so I'll explain the thought
> > process behind this in the hope that someone can point out where I may
> > be going wrong.
> >
> > In the Gallery Plugin, I want to be able to store preferences against
> > individual "Albums" and "Images" (e.g. "Sync this album to Gallery "My
> > Gallery" in Remote Album "My Digikam Photos"; or "Exclude this Image
> > from Sync." etc.).
> >
> > The Kipi API (to my knowledge) does not support such a generic
> > preferences scheme, so what was suggested to me is that I could use the
> > Album's folder name as a key in KConfig style configuration file and the
> > Image file name in a similar manner. This is OK, but it will only work
> > for Albums where Album==folder. Therefore I could not Sync e.g. a Tag to
> > a remote gallery.
> >
> > Personally I feel that *ALL* "folders" supplied to a Kipi Plugin are
> > virtual and that e.g. view of Albums are no different to views of Tags
> > etc.
> >
> > In addition, a kipi plugin should be able to hook into a KConfig like
> > interface for each Album/Image (where in this example an Album could be
> > an Album/Tag etc.)
> >
> > Does this make sense? What am I missing (there /has/ to be something I'm
> > missing!!!)
> >
> >> In libkipi, i would to add 2 new virtual method to set/get GPS position
> >> (altitude, longitude, and latitude) to set/get this informations from
> >> the host database. In digiKam will not support yet this informations,
> >> but in the future we will do it. These new methods will work exactly
> >> like set/get orientation methods do.
> >
> > This seems like a very specific method to deal with a specific plugin,
> > and doesn't seem to me to be too future proof (just the first
> > impression).
> >
> > Is there no way to achieve this generically? e.g. both of these methods
> > (GPS pos and orientaion) relate to editing the information that can be
> > stored in an EXIF tag (AFAIK!). Can these methods be generic such that
> > dealing these bits of data becomes effectively an edit operation on the
> > EXIF and then just have a way to tell the host application to re-read
> > the data (e.g. invalidate it's cached version of the data).
> >
> > I am using EXIF as an example here as I know that this may not apply to
> > all image types, but hopefully the more knowlegable people in this area
> > can see the point I'm trying to make.
> >
> > Just a thought.
> >
> > All the best
> >
> > Col.
>
> _______________________________________________
> Kde-imaging mailing list
> Kde-imaging at kde.org
> https://mail.kde.org/mailman/listinfo/kde-imaging