Output an image buffer abstraction

[nwin]

This library should return image buffers instead of byte slices.

[Boscop]

Yes, a higher level way to load and save animated GIFs (as a sequence of equally sized image buffers with their frame delays) would be very useful.

[kornelski]

That would be great. As I've mentioned in #35 I'd love if the buffer element had a type of the pixel, rather than u8.

I've tried implementing this a couple of times:

1. Allow any Copy type and only require that size_of of it matches something sensible (i.e. 4 if it's RGBA) - https://github.com/pornel/lodepng-rust/blob/master/src/lib.rs#L592,L600 https://github.com/pornel/libimagequant-rust/blob/master/src/lib.rs#L178,L185

   • it works with any user-supplied type, whether they want MyRGBA or (u8,u8,u8,u8) or u32 for it.
   • type inference makes it work automagically. Most of the time the user doesn't have to declare the type explicitly and they can just use the bitmap wherever they wanted.
   • it might be too lax and allow specifying inappropriate type

2. Require a common base crate for pixel types, e.g. https://crates.io/crates/rgb

   • this way the dependency on pixel type is minimal and decoupled from the decoder, so users can adopt the common crate without worrying about being tied to a bigger dependency/implementation detail.
   • trait orphan rules are annoying

There's probably a 3rd way, which could be an "adapter" sort of trait for the pixel type, so that users can make their own private RGBA type work with the library. The downside is that boilerplate is required to get started.

[nwin]

As I already mentioned, image_buffer will be used. Contributions/opinions are very welcome. 🙂

[Boscop]

Any updates on this? :)