DynamicImage.view().to_image() results in Rgba8 buffer even when source isn't

[jnickg]

It appears that if I create a SubImage from a DynamicImage by calling i.view(), and then call to_image() on that, I seemingly always get an Rgba8 ImageBuffer.

This is somewhat related to #2227, as I am running into the same UnsupportedError too, in a different place. I'll work on distilling the code down to a simpler example, but for now here's a link to my source where the problem occurs. Running that program as in ./target/debug/examples/make_tiles --input path/to/some.jpg --output path/to/out/dir --tile-height 64 --tile-width 64, I get the UnsupportedError when trying to save the results to JPG.

I am new to Rust so this is possibly user error here. Whether it's user error or a bug, that's where the problem starts, because as you can see in this block, the only "constructor" that compiles is ImageRgba8. If I try to use a match self.0 block to call the right enumerated DynamicImage value, all other ones throw errors such as mismatched types; expected struct ImageBuffer<Luma<u8>, _>; found struct ImageBuffer<Rgba<u8>, _>.

I am new to Rust so there's a good chance I am missing something obvious. Do I need to use some kind of type parameters to coerce the type I want? If so, what's the convention? Can this be documented? Copying ROIs out of an image is a pretty elementary image processing operation, so it would be good to have this process well known and documented.

What I don't understand is that since I am loading a jpeg with no alpha channel, I'd assume that the result of to_image() would depend on the type of image on which it was called. However, it is known at compile time that the type is an Rgba8 buffer, which seems to indicate that it's perhaps not behaving as intended.

Expected

to_image() should return an ImageBuffer of the underlying image's type.

Actual behaviour

It always returns an Rgba8 Imagebuffer, causing UnsupportedErrors when trying to re-save copied subregions of an original image.

Reproduction steps

See above description.

[fintelia]

Sorry, this is actually caused by a poorly designed part of the API. The DynamicImage type implements GenericImage<Pixel=Rgba<u8>> even though it really shouldn't. I tried to fix that in #2136 but discovered that it would probably break a lot of code.

The workaround is to avoid calling the GenericImage::view on DynamicImage. I think you can instead use the crop_imm method to achieve what you want

[jnickg]

No problem! Thank you for getting back to me. I just tested it and crop_imm seems to be working perfectly. Thanks for the info!

I will close this. 🙇