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

[Gilles Caulier]

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





--- Comment #140 from Gilles Caulier <caulier gilles gmail com>  2009-04-26 12:58:55 ---
>Hi, I'm the LqR team :) thanks for the invitation. 

Great !

>Also, I'm really glad you're
>using the liblqr library in DigiKam.
>Here are my remarks on what I've read so far:

ok

>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)

Julien(s), this tip is for you (:=)))

>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).

Idem

>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

Idem

>4)I've applied the last patch that Gilles requested

Fine. Patch are done by KDE core team who build whole KDE including digiKam
under a lots of different computers, OS, and compilers.

>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.

If you want, i can include this code in digiKam to test. 

For the moment, including lqr as well in digiKam is the faster way to hack and
code. Later, we will add an external depency of course.

>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. 

Damned, it will increase complexity. Unforget that we work too under windows,
and to add more depencies is really a mess under win32. I have fight a lots to
add a suitable GLib2 under Vista to compile and test digiKam Liquid Rescale
tool.

If you want to support more color model, why not to use lcms library ? It's not
enough ?

>(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.

In digiKam we only support RGBA (8 and 16 bits colors depth) not CYMK... which
is enough for 90% of case. CYMK is only for printing i think. Working in RGBA
and later convert to printer color model using the right print color profile
work fine.

Gilles Caulier

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