how does the speed compare with opencv?

[lucasjinreal]

how does the speed compare with opencv?

[Cykooz]

I have not yet done a benchmark to measure the speed of opencv.
I plan to do that after I add multithreading support. Because, as I understand it, opencv already has this feature.

[lucasjinreal]

@Cykooz hoping for it!

[negezor]

It would be nice to add a comparison with libvips.

[vhbit]

I would also love to see comparison with libvips (not only raw performance, but also peak memory usage)

[bend-n]

With threads turned off, the results look like this:

benchmark code: https://github.com/bend-n/imenchmark/blob/main/benches/resizing.rs

[Cykooz]

@bend-n Thank you for your work.

[Cykooz]

@bend-n I have only one note about your opencv benchmark. OpenCV doesn't have Lanczos3 implementation. It has only Lanczos4. Lanczoz4 is more complicated (requires more calculations) than Lanczos3.

[bend-n]

Oh yeah i forgot to rename the field to lanczos.

[bend-n]

re: libvips, i cant seem to be able to get it to work properly.

[Cykooz]

I have found out that OpenCV returns incorrect results if we downscale image with different interpolations. All results, except INTER_AREA, look like INTER_NEAREST. With such results I'll can't make any correct benchmarks.

Image bellow is result of downscaling with different interpolations (result was upscaled x2 for better pixels visibility).

[bend-n]

Why is that? Is opencv bugged? How is it for upscaling?

[Cykooz]

Upscaling looks better. I don't know why downscaling is so bad.

[Cykooz]

I've understood the reason. OpenCV uses "convolution" with fixed kernel size. In this case, downscaling very big image into very small one looks like a result of nearest "interpolation".

fast_image_resize uses convolution with adaptive kernel size. It requires more computations but makes more beter result.

It seems that only INTER_AREA in OpenCV uses real convolution with Box filter and minimal kernel size 1x1px.

[Cykooz]

@negezor I've done first comparison of libvips with fast_image_resize.
I've used libvips v8.12.1 from Ubuntu 22.04 repository.
libvips was tested in single-threaded mode with disabled caches.

	Nearest	Box	Bilinear	CatmullRom	Lanczos3
libvips	21.64	193.67	51.93	78.48	104.58
fir rust	0.86	61.49	97.43	165.89	232.39
fir avx2	-	20.23	21.74	28.14	41.13

[PRadeckiDH]

Hi @Cykooz, are you still planning to add multithreading support?

[Cykooz]

Yes, I am planning it.

[bend-n]

whats the point of multithreading it? if you want it to be faster, write it on the gpu. opencv is way faster when you let it use a gpu

[Cykooz]

Our servers don't have GPU.
OpenCV has only one "interpolation" mode that is similar to convolution with adaptive kernal size - INTER_AREA (look previous comments).

[bend-n]

you can just scale multiple images at once, no need to scale one image in parallel?

[Cykooz]

you can just scale multiple images at once, no need to scale one image in parallel?

That was exactly the purpose of writing the crate a few years ago. I use this crate to scale users images in a web service I am developing.
But now I want to add multi-threading support, which is more useful for single-user applications to work with single image at once (for example, image viewer application)

[Cykooz]

I released version 5.0.0. I added support for multi-thread image processing with the help of rayon crate.

[PRadeckiDH]

Awesome!! Will cykooz-resizer also receive multi-threaded support?

[Cykooz]

@PRadeckiDH Yes. I have plan to do it. I just need some time to figure out how to work with rayon thread-pool from python.