search

Cykooz / fast_image_resize

Rust library for fast image resizing with using of SIMD instructions.
Apache License 2.0
284 stars 25 forks source link

Support for `F32x2` `F32x3` & `F32x4`? #30

Closed virtualritz closed 2 months ago

virtualritz commented 3 months ago

Specifically for f32 TIFFs and OpenEXRs.

I can provide such files, to add to the data folder.

virtualritz commented 3 months ago

Here is a bunch of OpenEXRs. The names should explain what the data in there looks like.

Images were generated by me, I hereby put them under a CC0 license.

Cykooz commented 3 months ago

Thank you. But it seems that I can convert existing images on the fly to F32xN format for testing purposes.

virtualritz commented 3 months ago

Indeed, Krita or GraphicsMagick/ImageMagick or the like will do your bidding here.

The former is how I generated all those from a single F16x4 source.

P.S.: I can btw. also add F16x4 samples. It would be great to support the F16 types as well, behind a half feature that pulls in the resp. crate. :grin:

virtualritz commented 3 months ago

Btw, if there are any theoretical speed gains when doing e.g. three times a F32x3 vs. doing a F32x9? I.e. would it make sense, speed-wise, to support higher numbers than 4 for the channels (or even const-generics)?

OpenEXRs often have a lot of extra layers. E.g. normal (F32x3), albedo (F32x3) etc.

Cykooz commented 3 months ago

It would be great to support the F16 types as well, behind a half feature that pulls in the resp. crate. 😁

I think it will be possible with help of converting a f16-image to f32-one. As I know, modern CPUs haven't instructions to operate with f16 data type.

Cykooz commented 3 months ago

Btw, if there are any theoretical speed gains when doing e.g. three times a F32x3 vs. doing a F32x9? I.e. would it make sense, speed-wise, to support higher numbers than 4 for the channels (or even const-generics)?

If I do it in a generic style I will have to rename the crate to slow_image_resize :smiley:

Every pixel type that I add into the crate requires a lot of unique code and a lot of time to run benchmarks. So it is possible to add F32x9 but I doubt it's worth the effort.

virtualritz commented 3 months ago

I think it will be possible with help of converting a f16-image to f32-one. As I know, modern CPUs haven't instructions to operate with f16 data type.

Rust will "soon" have native f16 support which may make things easier. :grin:.

virtualritz commented 3 months ago

Also, there are finally some crates that do not render to stupid, non-linear u8. :wink:

E.g. Google's forma uses an [[f16; 4]] as storage for it's buffers.

Cykooz commented 2 months ago

I released version 4.1 with support of F32x2, F32x3 and F32x4 pixels.