I can't find anything in the documentation (or the source) that indicates that there is any support for conversion of data into a linear color space during resizing.

This is required to get correct results when downscaling images that are not in a linear color space. I.e. any 24/32bit PNG, 24bit JPG etc. one would find in the wild.

While this linearization could be done outside the resizing code (and thus this crate) for the supported i32 and f32 types, for the u8 case this is not possible. If the crate user linearizes the input data from some color space u8 to linear u8 there is too much loss of information – banding/posterization ensues. See example images in above linked article. For this reason the linearization before the filtering and de-linearization after has to be part of the resizing process itself for u8 grayscale or [u8; 3] RGB.

Would it be possible to add support for this? Basically u8 data needs to be linearized to at least u16, better u32 or f32, resized, de-linearized and stored back into u8. And the color space can't be baked into the crate. I.e. you can not just assume sRGB or gamma 2.2 if you want to do this properly.

Possibly through feature-flag gated support for e.g.:

• user-specified closures for transforming into/from linear color space during filtering
• a crate like colstodian

In case of closures the closure should have access to all components of a color so it can convert to/from other spaces, e.g. RGB to Lab, if the user wishes the resize to happen in that space.

Hi, I see that this project is able to resize a lot of different values but U8x2 seems to be missing.

What is the recommended strategy of working with LumaA pixels?

While debugging an (unrelated) memory leak in my own code using valgrind's memcheck tool, the following error was reported in this library.

Unfortunately I'm not quite in a state to be able to share some code to reproduce this error, but hopefully the output from memcheck will help

==1102663== Use of uninitialised value of size 8 ==1102663== at 0x3D3A64: fast_image_resize::convolution::u8x1::::horiz_convolution (optimisations.rs:113) ==1102663== by 0x3E72A3: fast_image_resize::resizer::resample_convolution (resizer.rs:285) ==1102663== by 0x3E3B95: fast_image_resize::resizer::Resizer::resize (resizer.rs:0) ==1102663== by 0x3B2C9F: vid_dup_finder_common::video_frames_gray::crop_resize_frame (video_frames_gray.rs:382)

Code here

use std::io::BufWriter;
use std::num::NonZeroU32;

use image::codecs::png::PngEncoder;
use image::io::Reader as ImageReader;
use image::{ColorType, ImageEncoder};

use fast_image_resize as fir;

fn main() {
    not_work(); // output: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

    work(); // output: [255, 196, 181, 255, 196, 181, 255, 198, 181, 255]
}

fn work() {
    let img = ImageReader::open("/dev/shm/0/1.png")
        .unwrap()
        .decode()
        .unwrap();
    let width = NonZeroU32::new(img.width()).unwrap();
    let height = NonZeroU32::new(img.height()).unwrap();

    let src_image = fir::Image::from_vec_u8(
        width,
        height,
        img.to_rgb8().into_raw(),
        fir::PixelType::U8x3,
    )
    .unwrap();

    let fix_width = NonZeroU32::new(img.width() * 2).unwrap();
    let fix_height = NonZeroU32::new(img.height() * 2).unwrap();
    let dst_width = fix_width; // fix here
    let dst_height = fix_height;

    let mut dst_image = fir::Image::new(dst_width, dst_height, src_image.pixel_type());
    let mut dst_view = dst_image.view_mut();
    let mut resizer = fir::Resizer::new(fir::ResizeAlg::Convolution(fir::FilterType::Box));

    resizer.resize(&src_image.view(), &mut dst_view).unwrap();

    eprintln!("{:?}", &dst_image.buffer()[0..10]);
}

fn not_work() {
    let img = ImageReader::open("/dev/shm/0/1.png")
        .unwrap()
        .decode()
        .unwrap();
    let width = NonZeroU32::new(img.width()).unwrap();
    let height = NonZeroU32::new(img.height()).unwrap();

    let src_image = fir::Image::from_vec_u8(
        width,
        height,
        img.to_rgb8().into_raw(),
        fir::PixelType::U8x3,
    )
    .unwrap();
    let dst_width = width; // bug here
    let dst_height = height;

    let mut dst_image = fir::Image::new(dst_width, dst_height, src_image.pixel_type());
    let mut dst_view = dst_image.view_mut();
    let mut resizer = fir::Resizer::new(fir::ResizeAlg::Convolution(fir::FilterType::Box));

    resizer.resize(&src_image.view(), &mut dst_view).unwrap();

    eprintln!("{:?}", &dst_image.buffer()[0..10]);
}

I am using this library to resize video frames from Gstreamer. Gstreamer sometimes creates frame buffers which are oversized.

When calling ImageView::from_buffer before resizing such frames, fast_image_resize returns error ImageBufferError::InvalidBufferSize. I expected that an oversize buffer would not cause an error.

For comparison, the image crate's "equivalent" type ImageBuffer::<Luma, &[u8]> does accept buffers which are oversized.

(It is easy to slice the buffer down to the right size before passing it into this crate, but it would be nice if this was not necessary)

(P.S. This crate is very fast :) -- it is nice to be able to resize frames in rust with competetive speed to resizing inside the Gstreamer pipeline)