Last time I checked this didn't do operations involving multiplications in linear space, i.e. any convolution or downscale operation would create wrong results.

Last time I checked this didn't do operations involving multiplications in linear space, i.e. any convolution or downscale operation would create wrong results. Everything was done in 8-bit/channel non-linear. It uses the 'image' crate's `ImageRgb8` type under the hood. As such I would also be surprised if did anything faster than the 'image' crate/its companion crate 'imageproc' (for the same operations, resp.). I think the 'image' crate may have fixed some of the non-linear issues in the meantime (but not sure). But 'photon-rs' on crates.io wasn't updated in two years and depends on 'image' v0.23.12 which does e.g. resizing in the input space, AFAIR. Also this crate confuses what is a color model with a what is a color space. Some of the supported "color spaces" are color models, some are indeed spaces. E.g. RGB is a model, as is HSV or HSL. While there are the 'colstodian' (1), 'kolor' (2) and recently the new (and very good looking) 'color' (3) crates to abstract the color space aspect nicely, the list of reverse dependencies on crates.io lays the issue bare (1: zero, 2: one when not counting colstodian and 3: a few but none of them dealing with image processing AFAIK). The ecosystem of Rust crates that get these things right is small because few people understand the signal processing math and color science. At the same time there are disproportional many crates that do some sort of image processing (as many people want to write/enjoy writing such a crate, it seems -- possibly theirs being "faster" or their API being "better" than everyone else's). To wrap up the bitching about the 'photon-rs' crate: it's name has an -rs suffix about which the official Rust API guidelines [3] have this to say: "Crate names should not use -rs or -rust as a suffix or prefix. Every crate is Rust! It serves no purpose to remind users of this constantly." And its getters start with `get_`, also a no-no in Rust, if you care about [3] (which you should, official naming guidelines are one of the reasons that make the Rust ecosystem a lot more "wholesome"). And now for some good stuff: If you want to see some really fast image processing in Rust that has built-in support to get the above things right, check e.g. the 'libblur' [1] or 'pic-scale' [2] crates, by the same author. They allow doing operations in non-linear space but they warn users about it and/or explicitly mention & provide avenues of doing the right thing easily, i.e. in doing everything in linear space (even when input & output is e.g. 8bit/channel sRGB). [1] https://crates.io/crates/libblur https://crates.io/crates/libblur [2] https://crates.io/crates/pic-scale https://crates.io/crates/pic-scale [3] https://rust-lang.github.io/api-guidelines/naming.html https://rust-lang.github.io/api-guidelines/naming.html Edit: footnote numbering.