KisIterator, quantum and pixels
cbr at boemann.dk
Mon Jul 5 22:10:59 CEST 2004
> 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
> will take. It would make it a bit easier to write iterators to display
> one channel.
> By the way, I'm still not convinced that it would not be useful to have
> ability to create different backends to store the data -- from banded
> to simple framebuffers, from tile managers to microtile structures, I
> like to keep open the possibility to exchange backends, and even have
> 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
> a good thing to copy. It looks to me like it's something caused by
> 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,
> we'll probably need to compose layers with different colour strategies,
> overlay selection masks and somehow handle adjustment layers. Not to
> 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
> > it.
> It's useful enough as a general concept to offer as an API so various
> that use this kind of thing can be as simple as possible.
> Another point is the type of iterators: currently we have line iterators
> point iterators in a line. This makes it fairly hard to move freely
> the data. On the other hand, for some purposes it is enough to move
> 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
More information about the kimageshop