theotherphil

Ok, thanks. This would be an easy change to make to the current code, but probably wouldn't play nicely with the changes we'd need to actually make this function fast...

We should also add helpers to initialise pixels to standard values. PixelType::White, PixelType::Black, etc. For the current Luma and Rgb pixels in the image library, this is the same as...

Thanks, I hadn't spotted that trait. I'd prefer to not have to impose a bound "where Pixel: FromColor" on these functions though. Black and white at least seem common enough...

I agree that it's important to get this correct. I don't have time to look at this myself at the moment. I suspect there's a bit of thinking to be...

I've got an initial (messy, slow) implementation of the algorithm in the linked paper here: https://github.com/theotherphil/rulinalg/commit/4f2355992487856c1e02662627efa9d9f4c875fa I'll tidy and speed it up before creating a pull request.

Hmmm. I've just found this: https://athemathmo.github.io/2016/08/29/inplace-transpose.html Looks like you've already done this! But it doesn't appear to have been merged.

I was googling for 128 bit integer support in Rust when I found your article! It looks like 128 bit integers should be getting stabilised soon. Fingers crossed.

The fast divide trick is already covered by an existing (nightly-only) crate. Might be worth reusing that when u128 is stabilised. https://github.com/fulmicoton/fastdivide

https://www.reddit.com/r/rust/comments/d4inkc/imagecli_a_pure_rust_image_processing_command/f0d07h0?utm_source=share&utm_medium=web2x https://imagemagick.org/script/identify.php Edit: created https://github.com/theotherphil/imagecli/issues/17

Thanks for the comment. This library currently only supports 8 bits per pixel: https://github.com/theotherphil/imagecli/blob/master/src/image_ops.rs#L195. This should definitely be fixed, but it won't be particularly easy. I intend to add support...