Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →
Fast_image_resize Alternatives
Similar projects and alternatives to fast_image_resize
-
slint
Slint is a declarative GUI toolkit to build native user interfaces for Rust, C++, or JavaScript apps.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
fast_image_resize reviews and mentions
-
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
[4] https://github.com/Cykooz/fast_image_resize/issues/3
[5] https://docs.rs/colstodian
-
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.
-
A note from our sponsor - InfluxDB
www.influxdata.com | 25 Apr 2024
Stats
Cykooz/fast_image_resize is an open source project licensed under Apache License 2.0 which is an OSI approved license.
The primary programming language of fast_image_resize is Rust.
Popular Comparisons
- fast_image_resize VS async-graphql
- fast_image_resize VS portable-simd
- fast_image_resize VS rawloader
- fast_image_resize VS image-sieve
- fast_image_resize VS exif-rs
- fast_image_resize VS watchout
- fast_image_resize VS slint
- fast_image_resize VS rust-blog
- fast_image_resize VS img-hash
- fast_image_resize VS photon
Sponsored