High-level pixel access methods

[Patrick Julien]

On February 15, 2004 07:27 am, Boudewijn Rempt wrote:
> On Sunday 15 February 2004 13:20, Patrick Julien wrote:
> > Why?
>
> I'm playing with code to simulate painting with water colours. Every pixel
> is made up from:
>
>   QUANTUM rd;  /*  Total red channel concentration */
>   QUANTUM rw;  /*  Myth-red concentration */
>   QUANTUM gd;  /*  Total green channel concentration */
>   QUANTUM gw;  /*  Myth-green concentration */
>   QUANTUM bd;  /*  Total blue channel concentration */
>   QUANTUM bw;  /*  Myth-blue concentration */
>   QUANTUM w;   /*  Water volume */
>   QUANTUM h;   /*  Height of paper surface */

That is not the point.

>
> (Where a QUANTUM needs to be at least 16 bits). And I can easily think of
> other paint types that need even more bytes, if I get down to implementing
> a wet & sticky model. I know that that's for the future, but I want the
> flexibility built in.
>
> I'm also looking into surface data like a paper height field and adsorbency
> into a KisSurface class, but I still need seven QUANTUMS for water colours,
> at least.

So, why do you need a MAX_CHANNELS at 255?

This code you are playing with?  Are all these values color channels, i.e. is 
it all data that would show up in the paint device?

I'm reluctant to bump MAX_CHANNELS any higher unless they are matching color 
strategies to support such a number of channels.