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 zero 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. Greetings, Ernst <ernstl@xxxxxxxxx>
