[Kde-imaging] Fwd: kipi hackers wanted

[Caulier Gilles]

Le Mardi 23 Mai 2006 12:39 PM, Caulier Gilles a écrit :
> Brett,
>
> I forward this message to kde-imaging mailing list. If you want to contribe
> in kipi project, please subscribe into this one.
>
> We will continue this thread in this room (:=))
>
> Gilles
>
> ----------  Message transmis  ----------
>
> Subject: [Kde-imaging] kipi hackers wanted
> Date: Lundi 22 Mai 2006 09:30 PM
> From: "Brett A. Taylor" <brett at realbt.com>
> To: Caulier Gilles <caulier.gilles at kdemail.net>
>
> Bonjour Gilles!
>
> I just realised yesterday that I wasn't subscribed to the list, and I
> missed your message. Oops!
>
> Anyway...
>
> > > Are you still in the need for a maintainer for jpeglossless? I would be
> > > interested in taking it on. I can tell you about myself and provide
> > > some evidence of my competence if you so desire. Just let me know.
> >
> > Brett,
> >
> > I have fixed some problem with JPEG loss less plugin about new release. I
> > have polished and commented the code (not realy maintened by Renchi Raju
> > since a long time).
> >
> > I'm agree that you maintain this plugin now. I can concentrate my effort
> > to other kipi parts, like SlideShow for example.
>
> Wonderful. I haven't maintained a package in KDE before, so kick me if I'm
>  not doing something properly. :-) I'm pretty excited to get involved with
>  KDE, especially digiKam-related stuff, which is absolutely wonderful...

Thanks about digiKam.

If you following my technical tips, This will be easy...

Unforget that Angelo is the kipi task coordinator. He will guide you too.

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

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

...

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

Gilles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kfile_tiff_trunk.patch
Type: text/x-diff
Size: 1842 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-imaging/attachments/20060523/827cedc6/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jpeglossless.patch
Type: text/x-diff
Size: 5015 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-imaging/attachments/20060523/827cedc6/attachment-0001.bin