CKMY craziness...

[Boudewijn Rempt]

On Saturday 20 November 2004 18:42, Saem Ghani wrote:
>
> Though, I wonder if this can be done with layers?  A simple wetness layer
> could be used in conjunction with each pixel layer?
>

That was the other possibility -- but there is really nothing that a 
watercolour paint layer has in common with an 8-bit rgb layer. It's not a 
simple matter of adding information to rgb, but rather the entire composition 
of a pixel is different.

To give an example, Raph Levien coded a watercolour simulation a long time 
ago, and his pixel is defined as follows:

struct _WetPix {
  u16 rd;  /*  Total red channel concentration */
  u16 rw;  /*  Myth-red concentration */
  u16 gd;  /*  Total green channel concentration */
  u16 gw;  /*  Myth-green concentration */
  u16 bd;  /*  Total blue channel concentration */
  u16 bw;  /*  Myth-blue concentration */
  u16 w;   /*  Water volume */
  u16 h;   /*  Height of paper surface */
};

In another pape the URL of which I have forgotten but which is up at the Krita 
website (I'm typing this on the train), the authors of a paint system use up 
to sixteen channels to simulate oils. I want this kind of flexibility 
possible, which is why I'm really glad with Patrick Julien's design of colour 
strategies: a generic data structure that can handle any type of 
2-dimensional data in a memory efficient way coupled with interpreters for 
that data.

> Taking in everything.  I think the simplest solution would be to have a
> struct, with an array of "channels" (they won't necessarily be colour
> channels, they could be wetness channels), a number of channels and a value
> storing the sizeof each element in bytes -- we can standardize this, say 8,
> 16, 24,  & 32 bits per channel, across pixel structs.  The only issue here
> is that one needs uniform data representation for everything, though one
> could employ clever tricks to encode many properties into say a byte using
> bitflags.  This would replace QUANTUM* out right and QUANTUM is just
> channel foo = myPixel.channel[x];  What data size we standardize along is
> going to be key.

That's very close to the original plan we developed this summer -- an if you 
create filters and other pixel-mangling code as templates on byte, int, 
float, then you don't have to agree on a single data size, but can offer any 
datasize that is useful.

-- 
Boudewijn Rempt | "Geef mij maar zuurtjes."
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20041122/3fda09d7/attachment.pgp