fast_image_resize
slint
Our great sponsors
fast_image_resize | slint | |
---|---|---|
3 | 138 | |
228 | 14,929 | |
- | 8.1% | |
7.7 | 9.9 | |
4 days ago | 6 days ago | |
Rust | Rust | |
Apache License 2.0 | GNU General Public License v3.0 Or Slint Royalty-Free |
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
[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.
slint
-
Ask HN: Why would you ever use C++ for a new project over Rust?
Did you get a chance to check https://slint.dev?
Disclaimer: I work for Slint
-
Deno in 2023
Currently, we do it by using binaries through napi-rs so we can bring in a window using the platform native API. And then we do some hack to merge the event loops.
But if Deno supports bringing up a window directly, this means we can just ship wasm instead of native binary for all platform. And also I hope event loop integration will be simplified.
Although we'd also need more API than just showing a window (mouse and keyboard input, accessibility, popup window, system tray, ...)
[1] https://slint.dev
-
Slint GUI Toolkit
Rich Text content is not yet implemented. This is tracked in https://github.com/slint-ui/slint/issues/2723
Thanks for reporting the broken link. Fixed in https://github.com/slint-ui/slint/commit/9200480b532f49007d2...
-
slint VS rinf - a user suggested alternative
2 projects | 24 Jan 2024
-
A 2024 Plea for Lean Software
With Slint (https://slint.dev) we're trying to make a lightweight toolkit that doesn't use HTML/CSS. And that you can program either from low level languages such as C++ or Rust. As well as with higher level language such as JavaScript, and we want to extend to python too.
-
Immediate Mode GUI Programming
I haven't. I was just searching for a GUI library that was Bevy-compatible and slint isn't at the moment: https://github.com/slint-ui/slint/discussions/940
Sorry!
-
Why the M2 is more advanced that it seemed
Trying to do that with Slint: https://slint.dev
- 9 years of Apple text editor solo dev
-
The Linux graphics stack in a nutshell, part 1
You can do that with Slint (https://slint.dev) and its linuxkms backend. No need for a xorg server or wayland compositor, just run the application made with Slint from the init script.
- Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
What are some alternatives?
async-graphql - A GraphQL server library implemented in Rust
tauri - Build smaller, faster, and more secure desktop applications with a web frontend.
rawloader - rust library to extract the raw data and some metadata from digital camera images
iced - A cross-platform GUI library for Rust, inspired by Elm
portable-simd - The testing ground for the future of portable SIMD in Rust
egui - egui: an easy-to-use immediate mode GUI in Rust that runs on both web and native
image-sieve - GUI based tool to sort and categorize images written in Rust
lvgl - Embedded graphics library to create beautiful UIs for any MCU, MPU and display type.
exif-rs - Exif parsing library written in pure Rust
dioxus - Fullstack GUI library for web, desktop, mobile, and more.
watchout - Automatically run scripts and reload images
cxx-qt - Safe interop between Rust and Qt