[Kde-imaging] Re: Implementation of legend feature in kipi slideshow plugin

[Renchi Raju]

On Sat, 10 Jul 2004, Stefan Wenk wrote:

> On Saturday 10 July 2004 14:20, Renchi Raju wrote:
> > hi stefan,
> >
> > thanks for your effort.
> >
> > On Sat, 10 Jul 2004, Stefan Wenk wrote:
> > > I wanted to see the comments for JPEG images in the slideshow, so I
> > > implemented this. The basic idea for the feature origins from the WIN32
> > > Irfanview program. See the modifications in the attachment. I did an CVS
> > > update today, so you should not have problems during merging.
> > > Besides the implementation of the new feature I fixed a bug, which caused
> > > a hangup when somebody presses the right mouse button just at the first
> > > image.
> >
> > please note: any extra-information that you display on the slideshow has
> > to come from the host application, as slideshow is a kipiplugin and will
> > be used by multiple applications. each application has its own standards
> > on what forms the "metadata" for an image and it provides this information
> > throught the kipi::interface. its required for a kipiplugin to respect
> > this metadata and not load any extra-meta-data from elsewhere for
> > consistency reasons. hence for the slideshow, the comments and any
> > extra-metadata you decide to display will have to be retrieved from the
> > kipi interface.
> Thanks for the information. It is true that the implementation only works for
> jpeg files and that it directly reads the exif information from the image
> file, if available. It seems that you are suggesting to make use of
> KIPI::ImageInfo. Here possibly the attributes() method could be used to
> exchange the exif information. But the documentation is quite unspecific at
> this point. (PENDING(blackie) document ). KIPI::ImageInfo::description (  )
> seems to return the comment for an image, I guess.  I don't see any advantage
> of using this interface in comparision to directly access the information,
> because as it is currently documented a plugin can't assume that all host
> applications will return the same information there. For this reason I don't
> intend to make an update of the modifications.

a kipiplugin should integrate well with the host application and so should
be consistent with the metadata provided by the application. overriding
the host app metadata to provide metadata from elsewhere goes against the
principles of KIPI. if the host app says this is a comment and the
kipiplugin ignores that, you will have surprises for the user.

> > please note: the jpeg comments are provided as a convenience feature from
> > digikam and these comments don't constitute the actual comments used by
> > digikam. the main comments are in the database and if a user wishes the
> > jpeg comments are kept in sync with the main comments.
> This is far away from beeing optimal, IMHO. I guess that you maintain the
> database in order to have access to centralised (e.g. tag) information, but
> the jpeg comments from the images should always override the information of
> the database. What happens if somebody manipulates an image with other
> applications, e.g. gimp, wrjpgcom or on another operating system. What
> happens if somebody sends an image, e.g. via e-mail and another person tags
> the image differently? Should then the users always re-enter the comment
> manually anew?

my reasons for not using jpeg comments for main comments in digikam:
a) works only for jpeg files.
b) very slow to access this information. especially if you have hundreds
(or even thousands) of images in an album, loading the album will lead to
heavy disk churn, seriously affecting the end-user experience
c) jpeg comments might (and often do) get overwritten by third-party
applications like gimp and compupic
d) dangerous - modifying an image just to add comments brings in the
element of risk of corrupting the image because of various reasons -
library bugs, program bugs, power failure...

renchi