Sergey "Shnatsel" Davidoff

Add basic fuzzing support for planned FFT, split by instruction set

1

This will only cover the combinations of the input and algorithm that the planner selects. It also doesn't perform correctness checks, only checking for memory safety issues. On the upside...

Fuzz testing

12

Since rustfft uses unsafe code for SIMD, it would be great to fuzz-test it with various inputs. A good introduction to fuzz testing in Rust can be found here: https://rust-fuzz.github.io/book/

Integrate the OpenClipArt SVG library to the test suite

4

When running the `wgpu_svg` example on the contents of `openclipart-svg` Debian/Ubuntu package I see multiple occurrences of #521 as well as other errors such as `Error during tesselation!: Internal(IncorrectActiveEdgeOrder(4))`. Since...

`jxl-oxide` spends 62% of the time in `copy_nonoverlapping`

3

I have converted a large image I had lying around to a slightly lossy JPEG XL with `cjxl -d 1`: [gast1verandering2_015_d1.jxl.gz](https://github.com/tirr-c/jxl-oxide/files/13953270/gast1verandering2_015_d1.jxl.gz) Decoding it with `djxl --disable_output` takes 50ms. With `jxl-oxide`...

Integration into the `image` crate

9

Would you be interested in adding `jxl-oxide` integration to the [`image`](https://github.com/image-rs/image) crate? It would be very convenient if users of `image` could decode jxl-oxide through its format-agnostic API without having...

Resizing images is slow

28

The image resizing routines in `image` seem to be really slow compared to the competition. For example, [`fast_image_resize`](https://github.com/cykooz/fast_image_resize) crate [benchmarks](https://github.com/cykooz/fast_image_resize?tab=readme-ov-file#some-benchmarks-for-x86_64) show that `image` is 5x slower than `libvips` and `fast_image_resize`'s...

High compression ratio mode for lossless WebP

2

WebP remains the lossless format with the highest compression ratio that is widely adopted. "Lossless" AVIF is not truly lossless due to the use of a custom non-RGB colorspace, conversion...

Google has recently published a new JPEG library that uses a number of tricks to produce higher-quality outputs at the same size (or same quality outputs at 35% smaller size):...

47% of the time is spent in `BoolReader::read_bool` when decoding lossy images

1

Decoding this file with `image-webp` is 1.8x slower than `dwebp -noasm -nofancy`: [Puente_de_Don_Luis_I,_Oporto,_Portugal,_2019-06-02,_DD_29-31_HDR.webp.gz](https://github.com/image-rs/image-webp/files/15171492/Puente_de_Don_Luis_I._Oporto._Portugal._2019-06-02._DD_29-31_HDR.webp.gz) ([source: wikipedia](https://commons.wikimedia.org/wiki/Commons:Picture_of_the_day#/media/File:Puente_de_Don_Luis_I,_Oporto,_Portugal,_2019-06-02,_DD_29-31_HDR.jpg), converted to lossy WebP using `imagemagick`) Profiling with `samply` shows [`image_webp::vp8::BoolReader::read_bool`](https://github.com/image-rs/image-webp/blob/ef0a23f0581f915bd11ce1a2112aa22af0dcbdfc/src/vp8.rs#L702-L744) being responsible for 47%...

More info here: https://github.com/rust-fuzz/cargo-fuzz/issues/174 This looks like an upstream bug - not even in cargo-fuzz but in libfuzzer. We need to figure out a minimal example and report it to...