Standardized color types

Hi,
Is there a package with standardized color definitions (struct), say, RGB, RGBA, CMYK,... (with u8 and f64 ∈ [0,1] types)? It seems to me that packages define their color representation making it painful to use together. Shouldn't there be an effort by the community to define a common ground for such basic elements?

Best.

Crate rgb - Rust is one such effort - for RGB/RGBA.

1 Like

While such an API may be nice to have (and make things easier in many cases), I'd like to point out that RGB != RGB, due to:

(see also color profile).

Some of these aspects can be safely ignored, depending on your application, but sometimes they can't. In particular these aspects are often also ignored when they shouldn't be ignored, resulting in bad or unexpected behavior when resizing images, for example.

P.S.: I just read in the rgb crate:

This crate intentionally doesn’t implement color management (due to complexity of the problem), but the structs can be parametrized to implement this if necessary. Other colorspaces are out of scope.

2 Likes

It looks like palette tries to address such things: https://docs.rs/palette/latest/palette/#its-never-just-rgb

1 Like

I actually just published a color space related crate but it only covers RGBA and hexadecimal notation. I've written a similar library to what the OP seems to have in mind in Zig, and even without factoring in color management it gets rather complicated. I'm not advocating that there can't be a great general purpose crate for the problem, but I tend to think that there are a lot of different use cases which might mean the exact solution might differ.

My application required being able to read a color from a Gtk+ widget, serializing it to Toml for storage in a config file, and conversion to hex notation for use in svg images. So a library with full color management and the ability to work in HSL, HSV, or CMYK are irrelevant. In fact since the svg is taking a six digit hex string I'm in practice limited to 8-bit power channel. I split it into a crate because, well, someone else might sometime find it useful. But it's hardly comprehensive.

Now, at the point that someone decides to write a full image or video editing suite with Rust their needs are going to be signifying more comprehensive. Hopefully when that time comes they'll publish their work as a crate.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.