finalizing the Iterator API

[Boudewijn Rempt]

On Wed, 7 Jul 2004, Cyrille Berger wrote:

> * about iterators
> Ok, here is my opinion, we needs two types of iterrator :
>  - one with line/column (as we already have, and as most image libraries have)

Yes, I see no problems with offering a rich set of iterators, provided they all
have the same basic api, and only differ in the way they move through the image.

>  - one increasing pixel after pixel, is there a need for this type of
> iterrator to follow a line ? I explain, it would be faster if the iterrator
> go through a tile, and after the end of a tile go to the next tile

Oh, good idea! -- for algorithms that work on a single pixel it's often
completely imaterial in which order the pixels are processed.

> > * PixelIterators return a pointer to Q_UINT8 (not QUANTUM, since that is a
> > remnant from the days Krita depended on ImageMagick for its core, besides
> > that gives the impression of being interpreted data already.)
> I disagree on this, PixelIterators should provide two operators, on that give
> the value and one that allow to set the value :
>         operator QUANTUM ();
>         operator=(QUANTUM v);

A point I'd overseen -- I was thinking, well we've got a pointer to the in-memory
representation of the pixel data, we can easily change it in situ within the colour
strategy. Good point, though.

>
> I thought that we have decided to keep QUANTUM until after the first release
> when we will search for the best solution to extend the notion ? (template or
> else)
>

That's why I put it around the last step in the Plan -- I don't oppose returning *Q_UINT
because that's essentially the same. The real bit-depth independence will indeed have
to wait until after Dathe first release.

> > * Colour strategies interpret the data delivered by the iterators, they can,
> > for instance, return a vector of channel values or a KoColor.
> This is exactly what my class give :
> class PixelRepresentation {
>         public:
>                 operator[](Q_INT32 a);
>                 operator=(PixelRepresention a);
> }

Isn't the the bone of contention that we want to

a) have access to the simple data, to pass to colour strategies
and
b) have an internally slightly more complicated iterator that returns this?

I thought I'd made the point somewhere that we should have both.

>
> > * Colour strategies have a ChannelInfo object (which I'll extend tonight)
> that
> > describes the way *Q_UINT8 will be interpreted
> In fact I add this object for dialog and especialy for use in the colorsfilter
> plugins.

Ah, so it was _your_ creation! I must admit I hadn't noticed, but it came in
uncommonly handy.

>
> >  * Ultimately, I want to get rid of much of the machinery in kis_global.h,
> like
> > QUANTUM and its ilk, and the PIXEL_XXX definitions that describe the
> position
> > in an array of QUANTUMS for each channel.
> I don't know what you find wrong with such mecanism ? I find they suit
> perfectly for RGBA, CMYN and grayscale. And you still need a way to determine
> to which channel correspond what.

I really hate the verbosity of things like

d[PIXEL_ALPHA] = (d[PIXEL_ALPHA] * (QUANTUM_MAX - srcAlpha) + srcAlpha * QUANTUM_MAX + QUANTUM_MAX / 2) / QUANTUM_MAX;

Which is why I'd like something a bit more clever. In fact, even a C struct where you can
go a.red is easier to read.