8 releases (5 stable)

Uses old Rust 2015

1.2.0 Jul 11, 2023
1.1.0 Apr 5, 2020
1.0.2 Oct 24, 2018
0.2.2 Apr 4, 2018
0.1.1 Feb 27, 2018

#155 in Images

Download history 522/week @ 2024-01-01 567/week @ 2024-01-08 266/week @ 2024-01-15 466/week @ 2024-01-22 524/week @ 2024-01-29 544/week @ 2024-02-05 803/week @ 2024-02-12 951/week @ 2024-02-19 809/week @ 2024-02-26 561/week @ 2024-03-04 479/week @ 2024-03-11 544/week @ 2024-03-18 554/week @ 2024-03-25 566/week @ 2024-04-01 521/week @ 2024-04-08 618/week @ 2024-04-15

2,316 downloads per month
Used in 5 crates

Apache-2.0

425KB
6.5K SLoC

Scarlet

Colors and color spaces made simple, for Rustaceans.

Build Status Crates.io dependency status Documentation

Humans and computers don't view color the same way, and so color descriptions like RGB don't effectively describe colors in the way that humans perceive them and vice versa. Image processing and other disciplines require the ability to interconvert and work with colors in a way that respects both how colors are displayed and how they are perceived by the human eye. Scarlet makes this not only possible, but simple and convenient. With Scarlet, you can:

  • Interconvert between different color representations
  • Work with colors in one representation using the concepts of a different one: for example, you can use a model of color luminance that accurately models human vision without leaving RGB, or modify a color's hue in CIELAB
  • Mix and average colors accurately, without kludges or results that look wrong to humans
  • Create perceptually-uniform color scales, colormaps, and gradients suitable for publication-quality visuals that don't mislead viewers
  • Convert a color to grayscale accurately and precisely
  • Accurately determine how far apart colors are perceptually.
  • And more!

Installation

Add this to your Cargo.toml:

[dependencies]
scarlet = "1.1.0"

and this to your crate root:

extern crate scarlet;

Documentation

Consult the documentation at docs.rs.

Contributing Guidelines

Before making a pull request, please consult the contributing guidelines.

The gist of it is:

  • Running cargo test should result in all tests passing. If tests themselves are wrong, change those in the pull request and explain the errors. Don't disable tests to make cargo test pass unless you have a really good reason!
  • If you make changes to the public-facing API, you should make sure that those changes are consistent with best practices and explain why you feel the API should change.
  • If you make performance improvements to code that already works, benchmark the change with test code that does things users would want to do and publish the results showing that your improvement actually improved something.
  • If you add new functionality, you should have test cases that thoroughly test that functionality.

General Philosophy

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

Dependencies

~13MB
~222K SLoC