JuliaAttic
for Julia 0.4: rename to Colors, rename ColorValue => Color
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.
:+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
You'll get into trouble that way if you're trying to pass a 3-component color array to C or if you're mmapping a 3-component file.
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.
