Converting DynamicImage into an ImageBuffer<P, _>

[trevorflahardy]

Hi there, I'm creating a function that aims to translate a given DynamicImage to an image buffer with type ImageBuffer<P, Vec<<P as Pixel>::Subpixel>>, here's what the goal is:

// A simplified version of an Image struct my code uses
pub struct Image<P: Pixel, U: image::GenericImage<Pixel = P>> {
    underlying: U,
}

pub trait FromWithFormat<T> {
    fn from_with_format(t: T, format: ImageFormat) -> Self;
}

impl<'a, P> FromWithFormat<&'a [u8]> for Image<P, ImageBuffer<P, Vec<P::Subpixel>>>
where
    P: Pixel,
{
    fn from_with_format(bytes: &'a [u8], format: ImageFormat) -> Self {
        let dyn_image = image::load_from_memory_with_format(&bytes, format).unwrap();
        let image: ImageBuffer<P, Vec<P::Subpixel>> = todo!(); // Some sort of macro that uses ConvertBuffer 
        Self { underlying: image }
    }
}

I looked into making a macro that does this similar to how the crate uses the dynamic_map! macro, however, I would need access to the FromColor trait (which is private) because of the bounds by ConvertBuffer... is there a way to do this that I am overlooking? Would it be easier to PR and make FromColor/IntoColor public or add a method onto DynamicImage that does this?

[fintelia]

What are you trying to use your Image struct for? I've found that trying to do image processing given only a impl GenericImage can be very limiting and that frequently you're better off either using a specific concrete ImageBuffer type or else a DynamicImage.

The core problem is that you can pretty much only apply operations that have been defined as required methods on the relevant traits. Which of course requires code changes within the image crate itself. In the case of color conversion, this is four methods on Pixel and a bunch more machinery around conversion between different primitive types.

I've so far been hesitant to stabilize and publicly expose the rest of the fully generic color conversion API because it felt very messy and not especially useful without being able to do much other generic image processing.

[trevorflahardy]

Hi there, thanks for getting back to me.

In short, I am currently working on a complex image merger project. The TLDR is that it merges multiple separate images into one larger canvas. To achieve this, I only need to use basic pixel operation methods like get_pixel, place_pixel, etc. GenericImage works fine in this case.

To simplify the user interface, I need to create the Image struct from a buffer in memory, like a Mmap or an opened file. Later down the road, I will need to convert an opened file to another format like Rgba from Rgb and vice versa for more complex mergers.

I understand your concerns about exposing the rest of the API and the complexity involved in doing so. However, I think it would be helpful to update the API in cases like mine, where there is a need to convert image types. One solution could be to replace all the to_x and into_x methods with a single method that uses generics. I'd love to help achieve this if needed :)

What do you recommend I do to overcome this issue? Thanks!

[fintelia]

I don't have a specific recommendation. One approach that might work would be copying the FromColor trait and implementations into your own code and then adding that additional trait as a bound on any of your methods that need it

[trevorflahardy]

Hey, thanks for getting back to me. I ended up brute forcing it with macros, which isn't a very elegant solution but it works for now.

Do you have plans to make that part of the API that we discussed public in the future? Thanks 👍

[fintelia]

No short term plans. My focus lately has been on image format decoding

[trevorflahardy]

Understood, thank you again for your time 👍

[drewcassidy]

Funny, I needed the same thing and just opened #2076. Doesnt allow arbitrary Pixel types but you can add a constraint