KisIterator, quantum and pixels
boud at valdyas.org
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
> > 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 | http://www.valdyas.org/fading/index.cgi
More information about the kimageshop