Austin Donnelly wrote:
> Actually, the core could do with a tile convolution, since currently
> it copies data into a tempbuf before convolving it.  This makes some
> tools more effificient (or incorrect) eg iscissors.

I'd love to see convolution in the Gimp core. I've written some code
that is pretty well optimized for larger convolution matrices, that
might be useful.
But there are several design issues that must be sorted out like:
* What data type for the convolution matrix? the current core only seems
to support integers, for my applications I found that floating points
are really necessary.
* How to handle image boundaries? Treating pixels outside the image as
gives in many case undesirable results, my code also supports mirroring
but several other options are possible.
* What sizes of convolution matrices must be supported? This is an
important issue. When you want to support larger matrices (e.g. 20x20)
the most efficient approach is to copy the tile that you are processing
and (parts of) neighboring tiles into a buffer and perform the
convolution on the contents of the buffer. In this way the inner loops
of the convolution can be much better optimized. When the size of the
matrix is small (say 3x3) it could be more efficient to use the data
from the tile directly (without copying) and to treat the boundaries of
the tile as a special case.

I am willing to do a large part of the coding, but only when there is
enough support for this issue from the "core" Gimp developers.

Gimp-developer mailing list

Reply via email to