https://bugs.kde.org/show_bug.cgi?id=251563 Summary: [patch] Getting rid of the lapack dependancy using
Eigen
Product: digikam
Version: unspecified
Platform: Gentoo Packages
OS/Version: Linux
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: Filter
AssignedTo:
[hidden email]
ReportedBy:
[hidden email]
Created an attachment (id=51754)
--> (
http://bugs.kde.org/attachment.cgi?id=51754)
patch to remove dependancy on lapack
Version: unspecified (using Devel)
OS: Linux
Original mail :
http://mail.kde.org/pipermail/digikam-devel/2010-September/045620.htmlI was very surprised (shocked?) to read
http://blog.akhuettel.de/2010/09/first-bump-digikam-140-kipi-plugins-130.htmlLot 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. 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).
Reproducible: Didn't try
--
Configure bugmail:
https://bugs.kde.org/userprefs.cgi?tab=email------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel
Locked
