KisIterator, quantum and pixels

[Casper Boemann]

> Well, as you say below we need to have an idea of what a channel is for a
> certain image type, just like we need to know how many bytes a complete
pixel
> will take. It would make it a bit easier to write iterators to display
only
> one channel.


> By the way, I'm still not convinced that it would not be useful to have
the
> ability to create different backends to store the data -- from banded
images
> to simple framebuffers, from tile managers to microtile structures, I
would
> like to keep open the possibility to exchange backends, and even have
several
> backends available at the same time.

I am convinced, but I'll not make anything that prevents that. On the other
hand I won't try to implement it either.

> Well, I don't think that having the alpha channel as a separate layer
would be
> a good thing to copy. It looks to me like it's something caused by
building
> on an older code base that didn't really support the feature. As for spot
> colours: it makes sense to make them a special layer, I guess.

Actually, true alpha channels should still be a channel. Photoshop's "extra
alpha channels" are however alpha layers, that when composed with the other
layers modifies the alpha channel. Another and better word for photoshops
"extra alpha channel" would be mask layer.

> We'll soon run into the limitations of our rendering strategy, though,
because
> we'll probably need to compose layers with different colour strategies,
> overlay selection masks and somehow handle adjustment layers. Not to
mention
> that there aren't many colour strategies that can be displayed directly -- 
> we'll soon want gamma correction even for rgb.

Yes different colorstrategies for each layer would be a problem. But not
just for us, but on a more conceptual level as well. The gamut of each
colormodel is not the same (actually out of gamut is a problem even with
composition of identical colorstrategy)

Simpler cases of one "true color strategy" composed with selection masks or
adjustment layers is somewhat simpler.

For display we should use lcms, and not do our own gamma correction. That
way we gain color profile abillity. But this can be done later.

> > sure, but an iterator for a kernel is perhabs overkill, but I don't
dispute
> > it.
>
> It's useful enough as a general concept to offer as an API so various
plugins
> that use this kind of thing can be as simple as possible.

> Another point is the type of iterators: currently we have line iterators
and
> point iterators in a line. This makes it fairly hard to move freely
through
> the data. On the other hand, for some purposes it is enough to move
linearly
> through all pixels without regard for lines.

Ideed, and I would like to move avay from that. To move throught all pixels
use my KisPixelExtentIterator

best regards
Casper Boemann