[Fluxus] colour commits

[Matt Jadud]

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.

Cheers,
Matt