KisIterator, quantum and pixels

[Boudewijn Rempt]

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 
prejudices.)

>
> 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 
http://java.sun.com/j2se/1.3/docs/guide/2d/spec/j2d-image.fm8.html.

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