KisIterator, quantum and pixels
boud at valdyas.org
Mon Jul 5 21:08:23 CEST 2004
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
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
> > 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'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
More information about the kimageshop