Title.

The consts.rs file runs into the problem that, as of now, Rust doesn't allow constants or statics to use functions to initialize. This means that every time we do any conversion, we generate the matrix from scratch, or do that and take its inverse. This is ridiculous, but it's hard to think of ways to fix it. We could add const fn, which is a nightly feature, but I'm unsure if that will even apply. We could store the inverses, but unless we do it to something like 15 decimal places we'll lose the preciison that made me use this library in the first place.

For ease of use and brevity, I've been using public attributes. Perhaps it'd be better to use getters and setters?

Travis CI offers status icons that can be embedded in the repository to track build status. Scarlet is tracked by Travis CI, and so it would be great if Scarlet showed its build status.

Travis CI publishes a guide on how to include the status image at https://docs.travis-ci.com/user/status-images/

We need a guide, with worked examples, on how to compare colors and what that means. Embedding colors as points can be really confusing: CIELAB with L = 0, a = -123, and b = 125 is the exact same color as L = 0, a = 100, and b = -124. Ditto for HSV and any chrominance-value system. We need a guide that clearly explains how to get color distances and why other methods aren't good enough.

Color::distance is already implemented, which gives a perceptual analog for color distance. It'd be helpful to have some sort of equality metric that uses this, perhaps both for exact equality and approximate equality.

The reason for this is because for chrominance-value spaces, like HSL and CIELCH, hue doesn't matter if the lightness is either black or white, so the hue value doesn't matter for equality metrics. Floating-point means that direct equality isn't super useful, though: perhaps it'd be best to do approximate equality using the XYZ method?

We need a high-level "how to" for working with gamuts and dealing with them correctly. I'll probably do this myself.

• Print output in image
• Make better shade illuminant

I need to clarify what's public and what's private: I think pretty much everything should be public, but that might create problems down the line. What, if anything, should be private?

We also need a "prelude" of sorts. This allows people to import things without having to dig through a bunch of files. I'm thinking Color, RGBColor, CIELABColor, CIELCHColor, XYZColor, Mix, and ColorPoint.

In my Emacs setup, strings such as #f0f that can be hex codes are automatically colored with that color. This makes it easy to see what colors look like. Adding this to our documentation would be lovely.

of course

I'll probably take care of this one myself, just so you know.

Rustdoc is nice and all, but a lot of crates lack the really crucial last step: a high-level guide that goes through common use cases. Giving people documentation on everything in the library isn't useful if people need to search all of that just to figure out how to do the thing they want to do.

I'm thinking worked code examples, that compile and do useful things, for things that people might want to do:

• Generate a triadic color scheme
• Equalize colors by luminance
• Compare the difference in various methods of getting grayscale versions of a color
• Replicate the famous Wright-Guild experiment (ok, probably better as a demo)

With something like this, where it's hard to explain what it does clearly to anyone who isn't a color scientist, it's especially important to have some cool demo or something that people can look at and then see parts of that functionality that they wanna use.

In the README you state:

To look at the general philosophy and API design of Scarlet, please look at api.org. This is more intended for developers.

The domain www.api.org points to the American Petroleum Institute, a website dedicated to natural gas and oil.

Which was the originally intended reference for API guidelines?

We currently just have linear gradients. It's sometimes nice to have other kinds, such as:

• Logarithmic
• Square root/cube root
• Padding the scale on either end (e.g., end 80% of the way there)

These should be easy to implement and are a good way to get started!

Every color space has a range of colors it can represent: for some, like CIELAB, this is simply the entire gamut of human vision, for others (like sRGB) it is much smaller. It is often desirable to get the closest color in one space that is representable in another one. This is pretty difficult to do and might require some pretty significant implementation: definitely one to tackle if you're feeling ambitious.

The docs.rs link to the colorized HTML file wasn't working, so I had to remove it. Now, without externally hosting it, there's no good way of getting colorized RGB output without user plugins, sadly enough. Not sure this is really fixable in this library.

I think nalgebra was perhaps not the best choice. I literally only want a couple of functions, but it's a really big library. I think something like rulinalg might be better suited.

I'm not sure if I need to import all the things I do. Even nonwithstanding that, I need to make sure there's only extern crates in lib.rs. We also might wanna use deps.rs.

For comparing XYZ colors, we have the approx_visually_equal method, which compares to a set constant that I can change. The problem is that in many other places in the code, I instead use one-off constants. That should change: either put them all using one method or make it a constant. That way, I can iteratively increase the precision of tests and fix the things that don't have that level of precision, like I did with XYZ colors.

CMYK is... very different from other spaces. It's subtractive, for one thing. Also, different printers are different. It's gamut is also a pentagon on the UCS diagram: bet you didn't see that coming!

I need to use cargo-external-doc here.

Parts of the library that don't have good test cases yet:

• Gradients
• Averages of a set of colors
• Gradient functions
• Visual indistinguishability method

The following code returns an AdobeRGBColor with all NaNs:

let color: AdobeRGBColor = Coord{x: -0.1, y: 100., z: -66.}.into();

https://en.wikipedia.org/wiki/HSL_and_HSV

Seems like rulinalg is no longer developed, and its also being flagged as having data race condition. I suggest replacing it with nalgebra.

In the goal to have Scarlet accept all forms of color input that CSS does, at some point functionality for accepting strings such as hsl(75%, 20%, 14%) for the HSLColor class.

There are some standard colormaps in data visualization that it's worth implementing. These include:

• The MATLAB and matplotlib ones
• A standard hue-based rainbow (this one is really bad for most things, though)
• Cubehelix and other ones that vary lightness evenly

Care has to be taken: some of these really don't have any uses, and so in line with Scarlet's philosophy we should probably only implement colormaps that people should actually use.

Lots of common traits need to be implemented or derived. These include:

• Serde's Deserialize and Serialize
• Hash
• IntoIterator for conveniently getting the components from the color
• ToString where feasible
• Display if possible
• Anything else I'm missing

Tests currently print all sorts of debugging nonsense. It's better to just stick to the demonstrations of color printing.

Part of the Rust API guidelines is that every public-facing feature should have a documentation comment with an example. We're currently 0 for hundreds on this score.

It'd be awful nice to be able to easily access the colors at Google's Material Design site.

There are lots of colormaps besides the standard matplotlib ones. Are there any that aren't simple gradients that we should do?

The colors.rs file has two types and two traits, totalling over 1000 lines of code. When I first made it, I didn't realize that Rust is much more generous with import cycles than Python, so it is possible to move some of that into its own place.

Docs.rs is breaking the intradoc links in many places. They work fine in local docs, though. Something to look into further. Hopefully soon the RFC on this will be stabilized so I can avoid this mess.