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

[Carlo Baldassi]

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


Carlo Baldassi <carlobaldassi at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlobaldassi at gmail.com




--- Comment #138 from Carlo Baldassi <carlobaldassi gmail com>  2009-04-26 12:39:02 ---
Hi, I'm the LqR team :) thanks for the invitation. Also, I'm really glad you're
using the liblqr library in DigiKam.
Here are my remarks on what I've read so far:
1)
"I have see that if scaling horizontally up to 150%, sometime preservation do
not work. I don't know why."
I suspect it is due to excessive enlargement. You should use the function
lqr_carver_set_enl_step(carver, enl_step) to overcome this. However, no
enlargement step is optimal in general. What I did in the GIMP plugin was
setting it to 1.5 and adding an option to change it. However, it should be
possible to approximately calculate the max amount allowed in order to keep the
preserved areas intact, like this:
max_enl_step = 2 - (pres_area_max_width / image_width)
where pres_area_max_width is the maximum number of preserved pixels in a line.
In this case, I still suggest to use a value less than 2 for the enl_step, and
do something like:
enl_step = min (max_enl_step, 1.5)
2)
I also recommend to call lqr_carver_set_side_switch_frequency(carver,
switch_frequency) with a small switch frequency (2 to 4 should be fine).
3)
Maybe I have missed something in your code, but I think you should free the
preservation/suppression mask buffer d->bias after the call to
lqr_carver_add_bias. BTW, looking at your code, I have decided that I will add
a new function to add a bias on pixel-by-pixel basis, so that you won't need to
build a buffer at all and the code will be more readble, I'll keep you posted
when it's done
4)
I've applied the last patch that Gilles requested
5)
I have almost finished building the new framework for the energy computation,
therefore it shouldn't take too long before version 0.4 of the library is out.
In the meeanwhile, there's a new branch in the git repo called "energy" which
is also compatible with the old framework (but documentation is still lacking).
It would be nice if someone else besides me tests it.
6)
I wanted to ask you if it would be a problem for you to also link to the babl
and/or gegl libraries: this is not for the immediate future, but I wanted to
take advantage of the facilities which those libraries provide to manage
different kinds of color models etc. (I have already addded some preliminary
support for CYMK images, but I think using a dedicated library would make more
sense and allow for a more general and optimised interface). If it is a
problem, I would add some preprocessing directives to the code when I do it,
and let the library be compiled with or without it, I'm just afraid it will
mess things up.

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