[Digikam-devel] about HSL optimizations

Gilles Caulier caulier.gilles at gmail.com
Tue Mar 9 10:38:08 GMT 2010

2010/3/6 Julien Narboux <jnarboux at narboux.fr>:
> Hi,
> The HSL filter contains an optimisation:
> http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/filters/hsl/hslfilter.cpp?revision=1089024&view=markup
> Instead of using the following simple algorithm :
> 1- convert each pixel to h,s,l
> 2- then add the parameters to the different channels h+ph, s+ps, l+pl
> and clamp the values
> 3- convert back to rgb
> The plugin precomputes all the possible values for h+ph, s+ps, l+pl
> using arrays of size 256 and 65635 and then apply the precomputed value
> to the picture.
> I would like to patch this to add a vibrance tool, it means that i want
> to change the saturation depending on the hue.

It's will be optional of course. I want mean, add a bool parameter to
HSLContainer to switch filter in this mode.

> This optimisation prevents me from doing that in a very simple way.
> So I tried a stupid patch to remove this optimisation.
> With a huge panorama of 54 mega pixels, I get 17 sec of computing time
> without the optimisation and 14sec with the optimisation.
> My question is the following:
>  Does it worth it ?

It's a profiling stuff to operate on you r code, to try to identify
where time consuming is lost.


Gprof give you the basic rules over, but you need to compile digiKam
with right GCC option. cachegrind and especially KCachegrind can help
you better in this way with to use a dedicated compilation option.


More information about the Digikam-devel mailing list