ImageBuffer from FFI *mut c_uchar data without copying

[raphaelmenges]

Hello 👋,

I am writing a Rust module to process images provided from a C++ environment. I want to make the processing as time and memory efficient as possible. In C++, the image data is created as unsigned char pointer with RGB color layout. In Rust, I receive a *mut c_uchar alongside the width and height of the image data. I am fiddling around with ImageBuffer::<Rgb<u8>, _>::from_raw but cannot wrap my head around it. Perhaps there is a (in)sane way to persuade Rust that I own the data and provide the data to an image buffer as container?

[fintelia]

The second generic argument for ImageBuffer is a container type that dereferences to a &[u8] (assuming the image is 8-bits per pixel). We almost always use Vec<u8> for it, but technically it can be any type. I think you should be able to do something along the lines of:

image::ImageBuffer::<image::Rgb<u8>, &mut [u8]>::from_raw(
    width,
    height,
    unsafe { slice::from_raw_parts_mut(data, width as usize * height as usize * 3) }
);

[raphaelmenges]

Cool! However, as soon as I want to apply filtering from the image-rs/imageproc-crate, the filter function expects an Image struct with an Vec as generic argument / container for the ImageBuffer:

pub fn filter3x3<P, K, S>(
    image: Image<P>,
    kernel: &[K]
) -> Image<ChannelMap<P, S>>

Sadly, there seems to be no sane way to transform a *mut c_uchar from C/C++ into a Vec in Rust to use that as container for the ImageBuffer. To my understanding, when a Vec takes over the memory of the data at the *mut c_uchar, it can lead to memory leaks and misallocations. The only solution seems to copy the data from *mut c_uchar the into a Vec, which is quite heavy for a 60hz stream of images on edge devices.

I am wondering whether there is any technical reason for explicitly using Vec in a context like above with the filtering, since the input image is only read and not manipulated.

[fintelia]

Non-Vec backed ImageBuffers haven't really gotten a ton of attention. It might just be a matter of making a PR against imageproc to make the relevant functions generic across backing container

[raphaelmenges]

Thank you @fintelia for the clarification!