[Fluxus] colour commits

[Dave Griffiths]

> On 6/25/08, gabor papp <gabor.lists at mndl.hu> wrote:
>> i committed some colour changes. now all expressions containing colours
>> should expect values in four formats:
>>
>>  (vector .9411 .2352 .145) ; rgb
>>  (vector .3784 .4411 .9039 .5) ; rgba
>>  .5 ; greyscale
>>  (vector 1 .3) ; greyscale + alpha
>>
>>  i also modified the hsv code and made it a bit more logical i hope.
>>
>>  usage of (opacity) is still not perfect. it overwrites colour alpha
>> elements of the current state if the opacity value is other than the
>> default
>> 1.0. i assumed if the value is not 1.0, the user is using the (opacity)
>> function.
>>
>>  please test the colour system. all comments are welcome.
>
> Hi all,
>
> I still haven't sat down and really *used* Fluxus, so mind the source.
> I'm an eager, not-yet-user.
>
> So: is there a reason for not using structures for this information?
>
> (define-struct color ())
> (define-struct (rgb color) (r g b [a #:auto] #:auto-value 0))
> (define-struct (greyscale color) (level [a #:auto] #:auto-value 0))
>
> This would give you constructors like
>
> (make-rgb .9411 .2352 .145)
> (make-rgb .9411 .2352 .145 .2)
> (make-greyscale .5)
>
> You would also get predicates like color?, rgb?, and so on. Then,
>
> (rgb? (make-greyscale .5)) ;; is false, but
> (color? (make-greyscale .5)) ;; is true
>
> because of the inheritance in the structure definitions. The optional
> field, available in the most recent releases of PLT Scheme, handle the
> alpha value by defaulting it to zero (or, perhaps that should be 1?).
> Either way, it would be one way to handle alpha levels: assign them to
> all colors by default. (This may be undesirable, but there would be
> other ways of handling the alpha.) It also might clean up underlying
> code, as there would be a way of cleanly, reliably discovering what
> type of information you're dealing with. Note, also, that structures
> in PLT Scheme don't impose much overhead compared to vectors.
>
> I have not looked at the Fluxus source, and have no idea how much
> effort a change like this would entail. However, it would eliminate
> the fact that a greyscale value is just a number, while a greyscale
> with alpha is a vector. Then again, this may just be a half-way
> solution to an object-oriented representation of color values, and all
> of it may be too much overhead with respect to the connection to the
> underlying C++ layer.
>
> Come to think of it, this might also be the kind of thing that goes
> against the livecoding ethos: I've just introduced a whole lot of
> typing... :)
>
> Either way, I thought I'd push it out to the list. It isn't my intent
> to snipe/criticize, really. Any time I see a bunch of random
> structured types being used to imply actual types, I just think it is
> a good place to impose real structure.

>From a graphics pov, there do indeed seem to be the two ways of doing it.
For instance, many graphics systems (eg renderman shader language) have
different types for points, normals and vectors - as the maths involved
with each is slightly different (eg. if you are transforming a normal or
vector, you want to ignore the translate part of the matrix as it doesn't
make sense for them).

The other way is to consider all these types as collections of numbers,
and supply different functions to operate in different ways - the hardware
shading languages (eg GLSL) do this, and fluxus has done it this way so
far.

I'd like to keep the C++ interface functions using plain vectors as it
makes things easier than supporting a multitude of types, but there is
nothing preventing us experimenting with more types in scheme.

So I suppose in the long term, I'd like to keep the low level fluxus
commands (i.e. the instruction set we are all using atm) as minimal as
possible, but also having another set (for instance, frisbee) which does
things much higher level way like this.

cheers,

dave