High-level pixel access methods

[Patrick Julien]

On February 14, 2004 03:28 pm, Boudewijn Rempt wrote:
> Perhaps a contradiction in terminis, but as noted a little while ago it
> would be nice to have efficient, high-levle pixel access methods. I said I
> would think about a proposal.
>
> We already have setPixel() and pixel() in KisPaintDevice, but one thing you
> cannot do is:
>
>  thisDevice -> setPixel(otherDevice -> pixel())
>
> And besides, I strongly suspect both methods of being very slow -- but I am
> not sure, of course, not having figured out how to do profiling in any
> other language than Python of Java yet.
>

Single pixel access from methods is always going to be slow, no matter when 
they reside.

> The other thing is that it would be nice to be able to retrieve an iterator
> that efficiently moves over the pixels in a rect of a KisPaintDevice.
>
>
> I came across this problem when hacking support for matrix transforms in
> KisPaintDevice using QWMatrix. Couldn't figure out how to loop with
> pointers over all the bytes in the tile manager without messing tiles
> myself -- a sure sign that the interface isn't yet high-level enough for
> mere mortals like me.

So, you basically want a way to access pixels on a line basis without having 
to think about tiles?


>
> I would like something like:
>
> in KisTileMgr:
>
> KisPixelDataSP getPixel(Q_UINT32 x, Q_UINT32 y);
> void setPixel(KisPixelDataSP pixel, x, y);

This would be just has slow, not only, but using KisTileMgr directly is 
discouraged.  The only reason why data() isn't private in KisPaintDevice is 
due to lack of features in KSharedPtr.

>
> And either a readPixelData() that doesn't copy all the pixels, or an
> iterator over the pixeldata (I prefer iterators over and above pointer
> arithmetic loops, even if I know how to loop with pointers, and don't know
> yet how to an iterator in C++. Besides the iterator could hide the tiles
> more easily, I think.)


Hmm, yes an interator that takes care of position in tiles would be quite 
possible... 

Well, at least for input, I need to think about this for random access...



>
> Would this be possible?
>
> (A third problem is that once we need to store more than five QUANTUM's of
> data per pixel, we're currently hosed, and if I get down to implementing a

why?

> kubelka-monk colour strategy, I need at least six QUANTUM's, and possibly
> more. And there may be places where it would be preferable to have growing
> stack of colour data, for instance when mimicking glazes) So making the
> pixeldata less dependent upon MAX_CHANNELS and the rest
> of the code less dependent on there always being the same number of bytes
> in a KisPixelData struct would be nice.)


MAX_CHANNELS is internal to tyles... in your own painting code, it is not 
necessary, use imgSomethingIForgetDepth() to get the number of channels... 
This should really be part of KisPaintDevice.