[Kde-imaging] Fwd: kipi hackers wanted

[Gilles Caulier]

Le Mercredi 24 Mai 2006 06:41, Brett A. Taylor a écrit :
> On Tuesday 23 May 2006 5:17 am, Caulier Gilles wrote:
> > > > With JPEGLossLess, still 3 problems :
> > > >
> > > > - Exif metadata to update when a JPEG file is transformed : Image
> > > > dimension informations and Exif Thumb. Using Exiv2 library is the
> > > > better way to do it (very easy, already done in digiKam core for the
> > > > same subject). In fact, libkexif depency need to be removed in all
> > > > plugins and remplaced by Exiv2 library.
> > >
> > > Sure, this sounds relatively simple. I'll get on this first.
> >
> > Take a care that to use Exiv2, we need to add a new depency into
> > kipi-plugins. I'm not sure that we can do it now, because we will have 2
> > libs depencies : libkexif and Exiv2.
> >
> > This is want mean that if we want a clean final kipi-plugins package,
> > libkexif need to be removed. To do it, all others plugins with use
> > libkexif need to fix fixed to use Exiv2 instead. To do it we need to have
> > the viewpoint from others plugins maintenors and from Angelo of course.
> >
> > For that, i recommend you to delay this task a little...
>
> Okay, well, I ended up doing most of the work on this yesterday. Exiv2 is a
> very nice library...
>
> I assume this all goes hand-in-hand with this bug:
> http://bugs.kde.org/show_bug.cgi?id=119537
>
> I'll leave it for the time being; but keep in mind that the conversion work
> is done for jpeglossless. I haven't started to look at the issue referenced
> in the bug (exif width/height updated). I don't suppose there's much point
> fixing that until we move to exiv2?

An implementation already exit in digiKam core from trunk to fix image size in 
Exif after rotation (from Cameragui). Look here :

http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/jpegutils/exifrotate.cpp?rev=540279&view=auto
http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dmetadata/dmetadata.cpp?rev=543272&view=auto

No need to re-invent the wheel. Get some inspirations from this code. No need 
to reproduce DMetadata class in plugin. Just get the right method.

>
> > > > - ImageMagick Exception rules are uncorrect : i have used Magick++ to
> > > > handle others file format than JPEG. C++ exception from IM are
> > > > uncompatible with Qt/KDE. We need to use MagickWand API instead. I
> > > > have a patch for imagerotate.cpp in my computer. still todo
> > > > imageflip.cpp and convert2grayscale.cpp.
> > >
> > > Can you send imagerotate.cpp to me? I can get started from that...
> >
> > The patch is attached to this mail. It use libMagick, not libMagick++.
> > You need to fix the Makefile.am.
> >
> > But, i'm not sure to link kipi-plugins with ImageMagick library is the
> > right way, because there are too main problem that i has identify :
> >
> > 1. Magick++ exception is uncompatible with Qt/KDE. The plugin crash !!!
> > We must use the C API instead the C++ API...
> > 2. There is an incompatibility between ImageMagick TIFF/EP loader and
> > TIFF-KFilePlugins from KDE API. This problem suck roally and crash the
> > host if the plugin is used with some TIFF files and if the host use
> > KFileMetaInfo class to parse the same file. This is the case of digiKam
> > from trunk when you enable the Properties side bar on the right of album
> > interface.
> >
> > About this problem, after to have investiguate indeep and with the
> > feedback from others developper (thanks to Marcel Wiesweg), this is not a
> > problem in digiKam, ImageMagick, or tiff-KFilePlugin, but a libtiff
> > conception problem about a common exception handler method. I can give
> > you more technical informations if you want...
> >
> > There is a patch from me for TIFF-KFilePlugin (not tested and not
> > commited in svn) joined to this mail. I'm not sure if this patch will
> > solve definitivly the problem...
> >
> > This is why, i think we need to process differently in this plugin with
> > all others non-JPEG file formats. Of course, we will use ImageMagick but
> > using Kprocess and the command line tool, like it does in
> > BatchProcessImages plugin. This is want mean that the thread
> > implemmentation in JPEGlossLess plugin will be only used to process jpeg
> > files and for all others, we need to use a new implementation.
> >
> > Using KProcess is easy. You have my implementation from BatchProcessImage
> > plugin like inspiration.
> >
> > If you is agree to use this way, you just need to parse all image file
> > formats to process with the current plugin instance, and processed
> > non-JPEG files in first with KProcess, and after the JPEG files using the
> > current implementation.
>
> Sounds like a good idea, but a lot of extra overhead to create the
> ImageMagick process like that. I suppose if we can't do anything about
> libtiff, this is the best way to go. (In reality, it's probably not much
> different creating the new process than it is loading the library... so I'm
> probably talking nonsense.)
>
> Anyway, I need to go for a bit of a swim in the code (mainly the other
> plugins) to make sure I fully understand what the problem is.

OK. Let's me hear if you need informations/help

Gilles