KisIterator, quantum and pixels

[Casper Boemann]

> I'm currently at work so I cannot give you a detailed answer about
iterators
> and so on, but please take time to read up on the previous discussion on
this
> topic on the mailing list.

Have already done that

> I'm very fond of Dr. Koethe's Vigra
> library (http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/) -- and
> especially his papers:
>
> http://kogs-www.informatik.uni-hamburg.de/~koethe/papers/handbook.ps.gz
>

I'll take a closer look tonight.

> The current iterator design needs some work, true, but I first want to
define
> the requirements and the design a bit more before we start an
implementation.
> For instance, handling bit depths > 8 bit by concatenating bytes won't cut
> it; there are image formats we want to support that need floats and
doubles.

In fact it is very possible to store float and doubles in this way. We just
need to do some C like casting of pointers inside the color strategy. There
is not even any performance overhead.

> Assymetric pixel types are best handled by leaving some precision unused,
I
> feel. And then there are more complex pixel types that I really would like
to
> support, like those described in:
> http://gamma.cs.unc.edu/impasto/Baxter-IMPaSTo_Web-NPAR04.pdf or in
> http://www.levien.com/gimp/wetdream.html (readable C source).

perhabs assymetric pixel types are best handle like that, but it wastes
memory  (many megabytes in a multi layered large image). And with my
proposal the decission is up to the colorstrategy.

Havn't read through those, but I asssume it is like the 7 channel example
you described in the mailarchive. And then it is easily handled by my
proposal.

> Another requirements for a redesign of the way Krita accesses image data
is to
> have as small an interface as possible. I wouldn't mind having an abstract
> pixel class that can be implemented for different pixel types

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.

> interface to the image data that's not much more than setPixel() and
> getPixel() to start with. Efficiency can come later.

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.

> I would like to be able to swap backends -- the tile manager is fine for
large
> images and images that need to store undo information, but something
simpler
> would be helpful for temporary layers, paste buffers etc.

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.

> 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

pixel yes, this is what I'm proposing.

> I am currently not satisfied by the lack of separation between the tile
> manager and the rest of Krita.

Yes I agree and as I said I'm investigating ways to do that.

Also, I too want to discuss this through before we start implementing.

best regards
Casper