about HSL optimizations

[Julien Narboux]

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

Julien


Here is the stupid patch: warning it is just a test for speed parameters
are not taken into account.

Index: libs/dimg/filters/hsl/hslfilter.cpp
===================================================================
--- libs/dimg/filters/hsl/hslfilter.cpp (révision 1099970)
+++ libs/dimg/filters/hsl/hslfilter.cpp (copie de travail)
@@ -198,8 +198,16 @@
             // convert RGB to HSL
             color.getHSL(&hue, &sat, &lig);

+            //julien test
+
+            hue=CLAMP065535(hue);
+            sat=CLAMP065535(sat+1000);
+            lig=CLAMP065535(lig+1000);
+
+
             // convert HSL to RGB
-            color.setRGB(d->htransfer16[hue], d->stransfer16[sat],
d->ltransfer16[lig], sixteenBit);
+            //color.setRGB(d->htransfer16[hue], d->stransfer16[sat],
d->ltransfer16[lig], sixteenBit);
+            color.setRGB(hue, sat, lig, sixteenBit);

             data[2] = color.red();
             data[1] = color.green();
@@ -222,10 +230,21 @@

             // convert RGB to HSL
             color.getHSL(&hue, &sat, &lig);
-
+
+            //julien test
+            /*
+            hue=CLAMP0255(hue);
+            if (lig>128)
+            {
+               sat=CLAMP0255(sat+20);
+            }
+            lig=CLAMP0255(lig+20);
+            */
+
             // convert HSL to RGB
-            color.setRGB(d->htransfer[hue], d->stransfer[sat],
d->ltransfer[lig], sixteenBit);
-
+             color.setRGB(d->htransfer[hue], d->stransfer[sat],
d->ltransfer[lig], sixteenBit);
+            // color.setRGB(hue, sat, lig, sixteenBit);
+
             data[2] = color.red();
             data[1] = color.green();
             data[0] = color.blue();

Julien




_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2010/3/6 Julien Narboux <[hidden email]>:

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

http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindWhat

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.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel