finalizing the Iterator API

[Boudewijn Rempt]

On Wednesday 07 July 2004 01:49, Cyrille Berger wrote:

>
> for instance in interlacing, or you may want to write a filter in which you
> do not change the pixel value the same way line after line, let say you
> want to draw a brick wall on your picture, you need to do something like :
> while
> 	for 10 lines
> 		every 20 pixels put a black pixel
> 	for 1 line
> 		make the entire line black
> That's simple but it may be usefull.
>

I see -- it might indeed be useful, but these are rather specialized use-cases, and I would prefer something simpler for the general case.

>
> I would like to remind that memory access are efficient if you access it by
> itteration :
> int* a = 10;
> int b = *a;
> int c = *(++a);
> int d = *(a+10); // is much slower than the line above
>
> I think that the day we will find it usefull, we will find a way to do
> this.
>

Fair enough -- although I am concerned that not having the ability to walk
a path through an image may hobble us when adding features without us realizing it.

> > These two points go together, I guess. One thing I really want to get rid
> > of is the whole [BLUE], [RED], [GREEN], [INTELLIGENT_SHADE_OF_BLUE]
> > idiom; interpreting the channels is the colour strategy's job, and no
> > doubt we can find a more elegant way of working with pixels or colours. A
> > truly universal pixel representation is perhaps hard to invent: the
> > closest I can come is a vector of channels, where a channel can be a
> > byte, an int, a double or a float.
>
> What the difference between a vector and what I proposed ?

Maybe I misunderstood: I understood you wanted something like KoColor as a returnvalue, while I simply wanted a QValueVector<Q_UINT8> or QValueVector<float> -- although I now realize that it's not very clever to use value vectors for that, since one doesn't want to copy the values all the time. And storing a separate pointer for all the values that make up a pixel isn't all that good an idea either, I see now. So I guess that returning a pointer to Q_UINT8 is best, after all.

Anwyay, having done a little iterating over images yesterday evening, I ended up with the following code:

		// iterators demand it. Something for the redesign.
		KisTileCommand* ktc = new KisTileCommand("histogram", (KisPaintDeviceSP)m_layer );

		KisIteratorLineQuantum lineIt = m_layer -> iteratorQuantumSelectionBegin(ktc);
		KisIteratorLineQuantum lastLine = m_layer -> iteratorQuantumSelectionEnd(ktc);
		Q_INT32 depth = ::imgTypeDepth( m_layer -> typeWithAlpha() );
		while( lineIt <= lastLine )
		{
			KisIteratorQuantum quantumIt = *lineIt;
			KisIteratorQuantum lastQuantum = lineIt.end();
			while( quantumIt <= lastQuantum )
			{
				for( int i = 0; i < depth; i++)
				{
					QUANTUM* data = quantumIt;
					// Do computing
					if (i == channel.pos()) {
						QUANTUM datum = data[channel.pos()];
						m_values[datum] = m_values[datum]++;
						if (datum > m_max) m_max = datum;
						if (datum < m_min) m_min = datum;
						total += datum;
						m_count++;

					}
					++quantumIt;
				}
				++quantumIt;
			}
			++lineIt;
		}

While what I would have wanted is more like the following semi-pseude-code, which also
shows the immediate problems I don't understand yet:

QValueVector<Channel> m_values;
ChannelInfo channelInfo;
KisPixelIterator it = KisPixelIterator(m_layer, m_layer -> hasSelection(), m_rect)
// XXX: Is this right -- do you actually ask the iterator for begin and end,
// or do you ask the KisPaintDevice for them? I'm confused now.
for (it.begin(); it != it.end(); ++it) {
	Pixel pixel = m_layer -> colorStrategy() -> pixel(it);
	Channel channel = pixel[channel.pos()];
	m_values[pixel[channel.pos()] = m_values[pixel[channel.pos()]++
}

A Channel can be a Q_UINT8, a Q_UINT32, a float or a double -- frankly 
I don't know how to model this so that we can work with data like this in
a generic way if we don't do it the Vigra way, or by using an interface
and classes like Java. We cannot and should not duplicate all code over
all colour strategies; there must be a generic way of handling this.


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