for Julia 0.4: rename to Colors, rename ColorValue => Color

[StefanKarpinski]

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.

[dcjones]

👍

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

[StefanKarpinski]

Would it be a horrible idea to just have alpha values everywhere?

[timholy]

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.

[StefanKarpinski]

Not if the type of the Alpha component is Nothing ;-)

[StefanKarpinski]

Or I guess a better choice would be a zero-field immutable whose numeric value is always one.

[dcjones]

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.

[StefanKarpinski]

I think your gut instinct may be right, @dcjones – it was just a thought.

[m-lohmann]

@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.

[timholy]

Given #57, it occurs to me that perhaps AlphaColor should be ColorAlpha, since the color component comes first in terms of memory layout.

[dcjones]

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.

[kmsquire]

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?

[JeffBezanson]

My gut reaction is that we should continue with a type per colorspace rather than handling some cases with parameters.

[timholy]

And now that we have AbstractRGB (#57), this should be easy.