RGB in 0-255

[stefanahman]

Is is possible to convert the RGB range from 0-1 to 0-255 to fit with the Plot.ly API: https://plot.ly/julia/line-and-scatter/

[Keno]

While I don't think that's an unreasonable change, I don't think the reason to fit with the Polt.ly API is particularly compelling, since any transformation could be done automatically. At least an out of range error might be nice.

[timholy]

Inside Images I've defined an RGB8 type, represented in terms of Uint8s. I have wondered whether it might be better to put it in Color.jl. Thoughts?

[jiahao]

Might be useful to have both RGB and RGB8, especially since the latter is used so extensively in images. But I'm not sure if that means RGB8 should live in Color.jl

[dcjones]

There are differing conventions for RGB: in colorimetry RGB is typically defined in [0,1], where computer graphics software and HTML, CSS, SVG, etc use [0,255], for obvious reasons.

I'd rather we stay with [0, 1]. It's fine to use [0, 255] if RGB is the only colorspace your system defines, but since we implement so many (and we're eventually going to implement multiple RGB colorspaces) it'd be best to be consistent about using colorimetry definitions.

Including RGB8 seems reasonable though if there's a strong need for it outside of Images.jl.

[stefanahman]

..or if it's possible to iterate over each element in RGB(r,g,b) and multiple by 255. It was just a thought to use [0, 255], since it's more common online.

[glennsweeney]

We could continue adding RGB(signed/unsigned)(8/16/32/float) types in Color, but this seems like it will get more and more complicated.

Would it make sense to always store RGB on 0->1 internally, and just provide a small function to allow people to convert in and out as they please? It seems like as we add more and more RGB types, things will get cumbersome. It also saves having to implement another set of converts for each RGB type.

You could also store the bit depth as "metadata" inside the RGB type, but this would add a huge amount of repetitive overhead.

Just a few thoughts.

[stefanahman]

Meanwhile:

function RGBto255(rgb)
  m = map((x) -> int(255*float(x)), match(r"(\d+\.?\d+),(\d+\.?\d+),(\d+\.?\d+)", string(rgb)).captures)
  return string("rgb($(m[1]), $(m[2]), $(m[3]))")
end

[dcjones]

If all you need is to turn a color c into a CSS-compatible color specification, you can also do this:

string("#", hex(c))

[stefanahman]

That also works, thanks!

[timholy]

@glenn-sweeney, just FYI defining the type as something like

immutable RGBPixel{T}
    r::T
    g::T
    b::T
end

adds no storage overhead: an array of RGBPixel{Uint8} would only require 3npixels bytes (discounting the array header), and an array of RGBPixel{Uint16} only 6npixels bytes, etc. Since the type is identical for all elements, you only have to store it once. So there is a sense in which you can have your cake and eat it too.

That said, I think Images' handling of color representations has a slightly different emphasis from Color's handling of color representations, and that this difference appropriately reflects the problems they are designed to solve. On balance I think it's probably better to leave something like RGBPixel in Images, and let Color stay focused on colorimetry (which it does oh-so-impressively well).

[glennsweeney]

@timholy Thanks, that is good to know!

I do agree; it's looking more and more like Color is working as a color specification "backend" to the image description that Images is doing. To Color, the actual bit depth of a sample is something of an afterthought. Perhaps keeping those "minor details" (ha, ha) in Images makes more sense.

[m-lohmann]

@glenn-sweeney In a purely colorimetric context the bit depth is unimportant. It’s important in the context of storing images. Even negative RGB values (out of gamut colors for any given device) provide important information for further processing, like determining appropriate colors for gamut compression if you convert e.g. from AdobeRGB to sRGB. Like the different rendering intents in Photoshop.

[glennsweeney]

I think that is exactly the point I was trying to make. However, Color also is not purely for colorimetry. Because packages such as Images is using Color's functionality, I think it is important to make a conscious decision about where different functionality (such as integer specification) is added.