[Digikam-devel] [patch] Getting rid of the lapack dependancy?

[orzel at kde.org]

Hi,

I was very surprised (shocked?) to read http://blog.akhuettel.de/2010/09/first-bump-digikam-140-kipi-plugins-130.html
Lot of people, and especially Gentoo people, think it's very bad to bundle copies of libraries (btw, I fully agree with them, but that's not the point here). Hence the gentoo package for digikam tries to use the systemwide lapack, which requires blas, and hence a fortran compiler.

Looking at the code, i could only see one single call to lapack : "dgesv_()" in libs/dimg/filters/sharp/matrix.cpp, which is a basic Ax=b solving (LU with pivoting). So one, and only one solving using a very common method makes digikam requires lapack/blas/fortran in gentoo, or, to stick with digikam point of view, lot of 3rdparty/ files in digikam source.

BUT, digikam already depends on KDE, which itself requires Eigen (http://eigen.tuxfamily.org), which provides such kind of linear algebra, and moreover in a very efficient manner, both code/API wise, and from a performance point of view.
Moreover, eigen was developed inside KDE to answer linear algebra needs among different KDE projects. Though it now lives its own way, there are still strong connections with KDE.

As you've probably guessed by now, I'm proposing a patch to do right this : use eigen instead of lapack to solve the linear system. Again, the dependancy on eigen is weak, as KDE already depends on it. I've used Eigen2 because eigen3 is not released yet (it's still in beta), and also because kde still depends on eigen2. I'll be  happy to update those few lines to eigen3 when required. In case you wonder, eigen works with a very broad range of compilers, oses, platforms, cpus... so it should in no way constrain digikam.

I've read http://www.digikam.org/drupal/contrib and the "HACKING" file and think/hope i comply with those. The webpage has great information such as "send patches this way", but no indication of where those patches should be sent, I hope this is the right place. By the way, i have write access to kde svn, but I of course would not dare committing such a patch without asking you first. That can be useful later on though.

I've not tested this yet, mostly because i dont know how to test it, and because i first want to get your 'go' on this before spending more times on the patch. At least it compiles, and i think it does the same as before, there really are few lines to consider. The return value from the lapack function was not used (it could tell if the system has no solution), so i've kept it this way.

If you happen to agree on the idea, I could test it with someone with more in-depth knowledge of this code, and then commit it. I'd like to make some performance tests, too, just out of curiosity.

The source code in libs/dimg/filters/sharp/ is really weird by the way, it's supposed to be C++, but it's actually struct, with lot of c-like functions such as 'create matrix', 'free matrix', 'copy matrix', and such. It looks like gtk. My main purpose was to remove the lapack dependancy/code duplication, so i did a minmalist patch, but there's a lot of room for improvement here, by switching to actual C++, and maybe use slightly more of eigen (convolution and other stuff).

Oh, and, last thing, i'm not subscribed to digikam-devel at kde.org, please CC: me. I'll try to look at the list archive.

best regards,
-- 
Thomas Capricelli
http://www.freehackers.org/thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20100917/41771ade/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digikam-move-to-eigen.diff.bz2
Type: application/x-bzip
Size: 46236 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20100917/41771ade/attachment.bin>