Open StefanKarpinski opened 10 years ago
:+1:
We should also think about what to do with AlphaColorValue
. Maybe something like
module Colors
abstract Color
abstract BasicColor <: Color
immutable RGB <: BasicColor
...
immutable AlphaColor{T} <: Color
...
end
Would it be a horrible idea to just have alpha values everywhere?
You'll get into trouble that way if you're trying to pass a 3-component color array to C or if you're mmap
ping a 3-component file.
Not if the type of the Alpha component is Nothing
;-)
Or I guess a better choice would be a zero-field immutable whose numeric value is always one.
It makes me a little uncomfortable to have the graphics part of this package encroach on the colorimetry part by making color inseparable from alpha values. But that's a superficial objection. If the alpha value could be "hidden" with an empty immutable it could work.
I think your gut instinct may be right, @dcjones – it was just a thought.
@dcjones Yes, alpha values don’t make much sense in terms of pure colorimetry because it would change the color coordinate depending on the background the color+alpha would be mixed with.
Given #57, it occurs to me that perhaps AlphaColor
should be ColorAlpha
, since the color component comes first in terms of memory layout.
The other potentially breaking change that's been brought up a few times is generalizing RGB
, since sRGB is far from the only RGB colorspace, despite being the most common.
I suppose we could do this by parameterizing RGB
by some type indicating the kind of RGB it is. So we'd have RGB{sRGB}
, RGB{AdobeRGB}
, RGB{CIERGB}
, etc, but define the RGB(r, g, b)
constructor to still default to sRGB. We may need to then parameterize HSL
and other colorspaces based on RGB in the same way, I suppose.
@m-lohmann, @glenn-sweeney, @rennis250 let me know if you have an opinion on how this should look.
I don't really have a dog in this fight, so take this with a grain of salt... but I'm wondering at what point things become over-parametrized, and it wouldn't just be easier to have separate types.
This may not be true here, but in this case, I'm curious what benefit a parametrized RGB type offers?
My gut reaction is that we should continue with a type per colorspace rather than handling some cases with parameters.
And now that we have AbstractRGB
(#57), this should be easy.
I agree with @JeffBezanson.
Best, R
Also, should it be Colors.jl or Colours.jl? :P
Farben.jl
I don't think this disruptive change would be warranted now, but since 0.4 is going to be a watershed release anyway, it might be a good time to shift names about a bit and this one has been bugging me for a while. The plural package name thing is becoming a bit of a convention in Julia packages.