KisIterator, quantum and pixels

Boudewijn Rempt boud at
Mon Jul 5 14:38:45 CEST 2004

On Monday 05 July 2004 14:13, Casper Boemann wrote:


> Which is in fact similar to my proposal. But I use C technique, because a
> true class can't reserve a runtime dynamic number of bytes as part of the
> class structure. Inside the colorstrategy the pixeldata can be cast to a
> specific class, if it feels better.

Which is the reason for using templates, I guess, because then you can let the 
compiler make the decision based on the pixel type.

> Yes simple, but it would however be too slow. The amount of data in an
> image requires efficient access,with small loops that remains in cache.
> Calling a function for every pixel is simply to much overhead. Sad but
> true. This is why we need iterators.

Mwah. I'm not convinced... (Don't take that too serious -- it's just that I 
really, really hate premature optimization, especially if it means 
complicating an interface. But I guess I'll just have to get rid of my Java 

> No I don't think so. There is no benefit from not using tiles, but the
> interface needs to be simpler. I'm working on that.

I'm waiting with bated breath -- although I still do thing that tiles give an 
extra overhead we don't always need.

> > But as for the iterators: it would be useful to have a set of iterators
> that
> > provide access by:
> >
> > * channel
> > * pixel
> > * kernel
> channel and kernel: please explain

channel: an iterator that skips the channels the caller isn't interested in. A 
kernel is a (often small) array of values used in convolution ops. An example 
of using a kernel for edge enhancement is at

Oh, and what I forgot: if we have tiles, we might have an opportunity of 
feeding the tiles to something that can parallel process them, as in vips 
(see the libs file in Krita's root for link).

Boudewijn Rempt |

More information about the kimageshop mailing list