[Kde-imaging] Fwd: kipi hackers wanted

[Brett A. Taylor]

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?

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

> > Again, sorry for the response delay. I missed your message. But don't
> > worry -- I'm getting on top of things.
>
> No problem. Welcome in the team.

Thanks for the welcome.


Brett