photon VS fast_image_resize

Image processing/transformations with built-in CDNs is one of the more common solutions you would find out there but can get pretty expensive and locked in over time.

Vercel is a good example that provides a built-in “next/image” solution for the NextJS framework that optimises images for better performance, however, it gets very expensive as you scale.

Alternatively, running your own service with one of the most common image processing libraries like SharpJS is great but can get pretty difficult to run in a serverless environment with CDNs and all the other bells and whistles alongside all your other code while the cold startup time of Sharp in a serverless environment can be pretty brutal.

With all the growth around rebuilding engines in Rust for performance gains, I thought there must be an image processing library written in Rust which could be compiled to WebAssembly (WASM) and run way faster. That’s when I discovered Photon https://github.com/silvia-odwyer/photon by Silvia, who has done amazing work with the library.

This eventually led me to discover https://github.com/fineshopdesign/cf-wasm/tree/main/packages... that has already transcribed the Photon package into a WASM binary for easy use in edge v8 environments like Cloudflare workers or NextJS Edge functions.

Using these packages I built an API layer on the NextJS framework allowing you to easily process local and remote images at blazing fast speeds with a bunch of helper functions making it similar to use as most paid Image processing APIs. If hosted on Vercel, you can make use of the built-in CDN cache for files less than 10 MB at no extra charge with Edge caching.

Some of the features:

- Blazing fast image processing

- Fully serverless, runs on Vercel Edge functions

- Resize, crop, compress, tint, rotate, format and more

- Global distribution with Edge functions

- Automated CDN cache with Edge functions

- Replacement for `next/image` processing on Vercel

- Local and remote image processing

Some problems:

- The Photon lib has last been updated in 2020

- There are still a few obvious bugs when using it for more advanced requirements like 8k image processing on edge function due to poor memory management in Rust

- No sexy features right now like AI image optimisation and selective background blurring

- If you are looking for an all-in-one solution with Image Storage + image processing/CDN, this is not it (something we will be releasing soon on JigsawStack.com)

I think the Photon library and the API have a lot more potential for growth and will be hoping for more contributions from the community as Rust gets more popular!

My first implementation was based on photon_rs, a Rust based web assembly library for image processing. It worked pretty well, but it was slower than OP website. Without digging much it seems logical since photon isn’t optimized for performance.

What you describe reminded me of photon. Check out the website. If there isn't an overlap of functionality then you can definitely integrate it into your own site.

For the image, you are able to either use your webcam to take a photo, or upload a photo of your own before moving onto the filters. Image filtering is included in most image manipulation libraries. I had used ImageMagick before, but had a terrible time with it. I wanted to find a better way to do Instagram-like filtering. I came across Photon, a high performance image processing library written in Rust and can be compiled to WebAssembly, and there was already a React demo so it was easy to integrate. Once you choose the filter you want, you move onto the decoration stage.

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

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.