[Digikam-devel] [Bug 149485] Advanced image resize for the digikam editor

Julien Narboux Julien at narboux.fr
Mon Apr 27 22:03:32 BST 2009


https://bugs.kde.org/show_bug.cgi?id=149485





--- Comment #160 from Julien Narboux <Julien narboux fr>  2009-04-27 23:03:30 ---
Andi, you are right speed should/could be improved.

1- First we should use the Lqr library properly, in the current code each time
we resize we rebuild every thing from scratch ! but Lqr library maintains data
structures to have a quicker rescale after the first rescale if we use it
properly, we simply do not use this for the time being, I will talk about that
with Gilles.
2- Second, Lqr implementation of the rigidity option may not be optimal, when
rigidity=1 (default value) It may be possible to write specialized code which
would be better optimized by gcc. From a post I read comparing ocaml
implentation of seamcarving and Lqr, it seems that Carlo is aware of that. 
3- Current implementation of Lqr computes the energy then finds the path of
least energy, then removes it, then updates energy, then finds again path of
least energy and so on... 
To compute the path of least energy in fact one computes all the paths of least
energy, so in fact several seams could be removed at the same time without
recomputing the updated energy. When need to study if this leads to too many
artefacts. Lqr author may implement this optimization in 0.5.
Look at http://liblqr.wikidot.com/forum/t-151301/how-implementation-works
4- Parallel computation: we could compute the paths of minimum energy using
several threads.
5- Seamcarving on GPU, it is possible to do I have seen on the web a student
who did this, but it is hard IMHO to get something portable.

Julien

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Digikam-devel mailing list