KisIterator, quantum and pixels

[Boudewijn Rempt]

On Monday 05 July 2004 20:34, Casper Boemann wrote:
>
> If I understand you correctly it's still a pixel iterator. One that goes
> from pixel to pixel. What you want is to extract specific channel info from
> each pixel. That is not the job of the iterator but should be defered to
> the colorstrategy. (as only the colorstrategy should know what to extract)
>

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.

> Still we need an abstract way to define channels so that from an ui point
> of view all colorstrategies can be managed in a similar way. By the way the
> spotcolorchannel and alpha channels of photoshop are not channels they are
> actually special forms of layers (non movable and always on top of the
> normal layers). If you have photoshop then try to select one of those
> "extra channels" while selecting layers. You can't - they are mutually
> exclusive. Anther hint is that those "extra channels" can be stacked in
> different order. On the other hand the layermasks of layers are actually
> true channels.

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. 

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. (By the way, I just went 
through the source for OpenEXR, and once we have 16 bit channels, displaying 
images will get very interesting, especially since I have no idea what an 
f-stop is, actually.)

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

I'll jot down a list of image iterator requirements right now, and post them 
when done; we can hack that proposal to pieces, and then start hacking...

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi