What’s the best way to convert DynamicImage into BGRX in sRGB colour space

[mina86]

I want to convert a DynamicImage into a buffer in BGRX format in sRGB colour space (where X means last byte doesn’t matter). My current approach is:

fn convert(mut img: image::DynamicImage) -> Vec<u8> {
    img.apply_color_space(
        image::metadata::Cicp::SRGB, Default::default()
    ).unwrap();
    let mut img = img.into_rgba8().into_vec();
    for pixel in img.as_chunks_mut::<4>() {
        let [r, g, b, a] = *pixel;
        *pixel = [b, g, r, 0];
    }
    img
}

However, in worst case it does three separate passes through the image. I wonder if there is a faster way of achieving what I want.

Should I use some kind of img.pixels().map(|p: P| -> [u8; 4] { todo!() }).collect() construction instead? But if that’s the way to go, how do I convert colour spaces inside of the closure and how to I convert subpixel to u8? Do I loose optimisations/parallelism if I don’t use apply_color_space and into_rgba8?

---

As added difficulty, ideally I’d also like to avoid memory allocation if the buffer already uses four bytes per pixel. Even if the image uses LumaA<u16> pixels, it could be transmuted into &[[u8; 4]]. However, that’s a rather minor point and I can live without it.

---

To give more context as to what I’m doing, I’m converting an image into one which X display server understands. X defines pixel colour as red, green and blue masks though I’ve limited myself to support 8-bit per channel with bit shifts.

[197g]

Currently you'll want to use DynamicImage::copy_from_color_space. It does not change the color representation so you can construct a DynamicImage to be used as a target from an existing buffer, transform in a way that changes both color space and channel representation, and then take back the original buffer.

use image::{DynamicImage, RgbaImage};

fn convert(src: &DynamicImage, buffer: RgbaImage) -> Vec<u8> {
    let mut target = DynamicImage::ImageRgba8(buffer);
    target.set_color_space(image::metadata::Cicp::SRGB);
    target.copy_from_color_space(src, Default::default()).unwrap();

    // Note: we know this does not reallocate, it's `Rgba8`.
    let mut img = target.into_rgba8().into_vec();

    for pixel in img.as_chunks_mut::<4>().0 {
        let [r, g, b, a] = *pixel;
        *pixel = [b, g, r, 0];
    }

    img
}

You can't fully avoid memory allocations with the image API in the general case. In particular we do not support overlapping inputs and outputs with different channel types / color layouts, the Rust mutable exclusivity makes it clear that this is a more difficult special case that requires extra attention in the implementation. We don't take on that complexity (yet?).

---

You may have some luck in image-canvas in an unreleased git version. With time it may become the backing algorithmic implementation but it is a quite unsafe-heavy experiment, as of yet, and moxcms provides a faster conversion of the current cases on many targets. But I'm using it myself for interaction with /dev/fb on a Raspberry.

Notable the above does not address endianess concerns, if your target buffer can be Rgb656 you need more touch-ups after the conversion anyways, I wouldn't worry too much about the multi-pass solution as the bottleneck for now.

[197g]

If you can take ownership of the src buffer you may implement a fast-path in the above solution that does not allocate a separate target buffer.

let mut img = if let Some(mut rgba) = src.as_mut_rgba8() {
    rgba.apply_color_space(image::metadata::Cicp::SRGB, Default::default());
    src.into_rgba8().into_vec()
} else {
    …
};

[mina86]

I’ll take a look at the crates, but in the meanwhile copy_from_color_space by itself is an improvement. Thanks.

I wouldn't worry too much about the multi-pass solution as the bottleneck for now.

Well, it is my personal project, so I’ll waste time on imperceivable performance improvements if I want to, thank you very much. :P It’s more of a curiosity/challenge of figuring out how efficient it could be done. In my case the bottleneck is resizing whenever I need to do it and I’m currently playing around comparing with fast_image_resize.