fast_image_resize
exif-rs
Our great sponsors
fast_image_resize | exif-rs | |
---|---|---|
3 | 2 | |
228 | 178 | |
- | - | |
8.1 | 0.0 | |
2 months ago | 26 days ago | |
Rust | Rust | |
Apache License 2.0 | BSD 2-clause "Simplified" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
fast_image_resize
-
Rust/WebAssembly image processing library
Unfortunately mostly useless for professional applications.
It fails the most simple test from [0] in the online demo[1]. ImageMagic also has a page about this[2]. I.e. also try the 'city lights' test with the online demo to see it fail for the same reason.
The issue is that if you write code that deals with color you must understand color spaces and gamma. A non-linearly encoded color can't be plugged into any of the math you use to manipulate images and get meaningful results.
Almost all code I come across in the Rust ecosystem (or elsewhere no less) treats color as linear. But color incoming from image files that are not RAW, EXR or some TIF variant is almost /never/ linear.
The reason is that it is written by people who are (often very skilled) software developers but lack any basic understanding of color science.
And then it often takes convicing the maintainers first and the yonx before it is fixed. I'm speaking from multiple experiences here.
For example, the fast image resize crate[3] addressed the resp. issue I filed last Dec.[4] less than a week ago. From the crate being released in the wild to it adding an option to treat color correct almost 1.5 years passed.
This is not the same as forcing crate users to treat color correct btw. The crate added a function that calls a closure but a user who do not understand color science may not grok why this is needed and not use it.
I guess I'm saying there is also often an 'UX' issue that perpetuates the problem to the user side of the API after the crate itself addressed it somehow.
That said, there are some very good crates that abstract the resp. parts away to address the issue. E.g. [5].
[0] http://www.ericbrasseur.org/gamma.html?i=1#explanation
[1] https://silvia-odwyer.github.io/photon/demo.html
[2] https://legacy.imagemagick.org/Usage/resize/#resize_colorspa...
[3] https://docs.rs/fast_image_resize
-
Announcing: ImageSieve, a tool to assist in sorting and archiving images and videos
I absolutely loved all the crates available that made my life very simple in many cases. I used (among others) the slint ui framework, kamadak-exif, img_hash, fast_image_resize and rawloader.
- fast_image_resize - crate for fast image resizing with support of SIMD instructions.
exif-rs
-
Hey Rustaceans! Got a question? Ask here! (27/2022)!
I dont want the files to waste a lot of space so i decided to resize them. For that i used the resize method from the "image" crate. Everything works fine, until i start to upload images above 5mb. Then the resize method starts to rotate the images. I think i narrowed it down to the resize function deleting any existing exif data inside the image file. That way the orientation flag is removed and the image is in its default position. I already tried to fix this, by saving the exif data before resizing and then rewriting it to the image file. The only library that i could find that supports writing (at least for png and jpeg) was this one: kamadax-exif. The problem is, that when i write the exif data (all the previous data or just the orientation data) the file gets corrupted. Now to my question: Can someone recommend a library that can resize images, that preserves the aspect ratio and does not delete the exif data? if not, does someone have an idea on how to resize the images differently? Or maybe there exists another exif data crate that i can use? I hope this question is understandable, thanks in advance :)
-
Announcing: ImageSieve, a tool to assist in sorting and archiving images and videos
I absolutely loved all the crates available that made my life very simple in many cases. I used (among others) the slint ui framework, kamadak-exif, img_hash, fast_image_resize and rawloader.
What are some alternatives?
async-graphql - A GraphQL server library implemented in Rust
img-parts - Low level crate for reading and writing Jpeg, Png and RIFF image containers
rawloader - rust library to extract the raw data and some metadata from digital camera images
portable-simd - The testing ground for the future of portable SIMD in Rust
image-sieve - GUI based tool to sort and categorize images written in Rust
rust-analyzer - A Rust compiler front-end for IDEs
watchout - Automatically run scripts and reload images
img-hash - A Rust library for calculating perceptual hash values of images
slint - Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
exiftool-rs - Image metadata scrubber written in Rust.