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

[Carlo Baldassi]

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





--- Comment #173 from Carlo Baldassi <carlobaldassi gmail com>  2009-05-05 16:16:02 ---
The new version of the library is now ready and available from the git repo.
The documentation and the example files are also updated.
Main news with respect to my last comment #165:
1) optimisation which produces a very noticeable performance gain in some cases
(@ Julien N.: after all, the crude hack which was considered in the ocaml
implementation thread was applicable, but most of the gain comes from a tiny
approximation which spares some cycles).
2) possibility to define custom energy functions
3) possibility to output the energy for plotting

About the last point, there are 2 ways in which one could provide previews for
the energy:
1) use a single LqrCarver object all the time; create it, then allow the user
to choose the energy function and plot it, then initialise the carver and do
the rescaling
2) create an independent LqrCarver for energy preview purposes only (without
initialisation - and using preserv_input_image - it is relatively inexpensive,
since it is essentially like "dressing up" a buffer; also, a bias can be added
to it).
The second way is probably quicker to implement, but in some cases it may be
less optimal; the first way would be better if you plan to keep the carving
information between trials.

Please, report me any bugs/problems you might find, and also if the
documentation is not clear or is incomplete etc.
I wish to release it by this week-end, so please help me sorting out any
possible issue.

@ Julien #172:
> perhaps we can compute each line in parallel using several cores. For example > one core could compute the left hand side and another one the right and side > of a line.
Yes, that is in fact the only possibility given the current implementation. Due
to the optimisation, however, the second way (using only 2 cores) would be the
only one applicable, and I'm not sure it would provide a great advantage due to
the sync overhead (as you pointed out).
Before implementing that, I'd rather think about a way to truly distribute the
computation, e.g. by using a different representation of the internal states at
each pixel.

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