After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 166406 - Unsharp Mask slow at large radius
Unsharp Mask slow at large radius
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Plugins
2.2.x
Other Linux
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-02-06 00:07 UTC by Peter Heckert
Modified: 2008-01-15 12:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Peter Heckert 2005-02-06 00:07:00 UTC
Hello,

unsharp mask is *very* slow, when the radius is about 50 or more.
(I use this setting for local contrast enhancement)

I was looking into the code and found a reason why.
--------------------------------------------------------------
      /* go through each pixel in each col */
      for (; row < len - cmatrix_middle; row++)
        {
          src_p = src + (row - cmatrix_middle) * bytes;
          for (i = 0; i < bytes; i++)
            {
              cmatrix_p = cmatrix;
              src_p1 = src_p;
              ctable_p = ctable;
              sum = 0;
// Original code             for (j = cmatrix_length; j > 0; j--)
/* My code */              for (j = 0; j < cmatrix_length; j++) 
		{
// Original code                 sum += *(ctable_p + *src_p1);
/* My code */                  sum += cmatrix[j] * *src_p1;

		  src_p1 += bytes;
                  ctable_p += 256;
                }

              src_p++;
              *dest++ = ROUND (sum);
            }
        }

------------------------------------------------------------------------
Obviously it uses a lookup-table to speedup multiplications, but this
will overload the processor cache and doesnt use data prefetching. (I use AMD-Duron)

After I made the alterations shown above, it was at least 5 times faster.

Ok, there are other things to improve, eg. edge-condition handling.

Also selective gaussian blur gets *very* slow at large radius.
Possibly it has similar reasons.

regards,

Peter
Comment 1 weskaggs 2005-02-06 19:45:01 UTC
I tried your change (Intel P6), and also got about a 5-fold speedup (for large
images) using a radius of 60, so I have applied the change to cvs HEAD.  It
would be nice if people with non-x86 systems could check that this change does
not worsen performance for them.

The factors that make selective gaussian blur slow are quite different; see bug
#142711.

I will resolve this as FIXED, but feel free to add comments if there turn out to
be unpleasant consequences.  

2005-02-06  Bill Skaggs  <weskaggs@primate.ucdavis.edu>

	* plug-ins/common/unsharp.c:  apply speedup proposed 
	by Peter Heckert in bug #166406.  
Comment 2 Peter Heckert 2005-02-07 17:07:53 UTC
Thank you. This resolves the problem for now.

When gimp goes 16 bit, then this plugin must be rewritten anyway and the
lookup-table would become useless then. So in near future this must be rewritten
anyway.

Photoshop and paintshop are much faster with unsharp mask and selective blur and
I believe they use a recursive blur algorithm, where the processing time and the
number of multiplications is independent from the kernal-size. 
Such algorithm's are existing, but I am curenntly unable to implement them; I am
not a specialist.

People in <news:sci.image.processing> and <news:comp.graphics.algorithms> should
know mor about this, and in fact, I got my knowledge from there ;-)

This would be the future way to go, and it would not make sense to spent too
much work for the current plugin-version.

Thanks for your work.
Gaussian selective blur and unsharp mask are the only blur's I really use.
The other blurs (IIR and RLE) are pretty fast but I never need them. That's live ;-)

regards,

Peter