image VS oxipng

I started by exploring the audio processing part and then I discovered Symphonia which is a rust crate for audio processing. First I build a function to extract mono audio from a file using it and kept a frequency limited to 41.1 KHz as it is the maximum frequency that the human ear can hear. I also implemented functions to downsample the audio and normalise it. Then I visualized the spectrogram of the audio using image.

With the help of the image crate, loading an image from disk is fairly straightforward.

FTR there is a WebP decoder implementation in safe Rust in the image crate: https://github.com/image-rs/image

It used to be quite incomplete for a long time, but work last year has implemented many webp features. Chromium now has a policy of allowing the use of Rust dependencies, so maybe Chromium could start adopting it?

Hello! So I have a local app that I am currently running on desktop (windows). I'm using egui for the UI, and the program basically opens a folder, gets all the images in the folder, and then uses the image-rs library to resize and create a grid of images / some other operations.

png is the de-facto standard Rust crate for reading and writing PNG images, used e.g. by the image crate.

There's also a CLI to convert between formats. It uses the crate image.

exr is a is a 100% Rust and 100% safe code library for reading and writing OpenEXR images. It is used by the popular image crate to read and write OpenEXR.

We're currently looking for contributors to add support for zune-jpeg to the image crate. The image maintainers are open to it, but don't have the capacity to do it themselves. You can find more details here.

It would be helpful to contribute to the general change towards an untyped buffer with runtime representations for color space information and fallible conversions. (https://github.com/image-rs/image/pull/1718). It's currently stalling on having too few eyeballs to judge the impact and need for that complexity.

While mostly true, there's a large problem with lots of these Rust CLI tools (and I use some of them, don't misunderstand me): they often discard the UNIX philosophy in favour of newbie friendliness and glitter.

For example, ripgrep shouldn't merge find and grep (actually, I use a personal wrapper around `find ... -exec grep ... {} +` because my only beef with this is that find's syntax to exclude stuff is horrible, https://git.sr.ht/~q3cpma/scripts/tree/master/item/find_grep). Or you see something like https://github.com/shssoichiro/oxipng/issues/629 because people don't even know how to use xargs...

I have had good experiences with https://github.com/shssoichiro/oxipng . Although, I suspect this wouldn't give you nearly enough space savings as jpg.

If you do want the file as a PNG (for transparency and a common format that's well supported), but don't want it so huge, consider something like oxipng. https://github.com/shssoichiro/oxipng

oxipng, pngquant and svgcleaner — optimizing images

I wonder how `pngcrush` compares to `oxipng` (https://github.com/shssoichiro/oxipng).

Personally, I use `oxipng` if I want lossless compression. However, most of the time, I use `pngquant` instead, since it gives significant size reduction even at `99%` (I can't even distinguish between the original and reduced image).

    pngquant --quality=99 --ext=.png --force file.png

Depending on your workflow it might make sense to export PNGs directly from Affinity and then reduce their size with a utility like Oxipng, which uses all your cores to find the best algorithm for each particular image.

Assuming your frames are PNG files, you could use a lossless optimizer like optipng to try if their size can be reduced. I prefer oxipng, which is faster and multithreaded, and seems to have more active development.