ImageBuffer) is most often additional overhead while being rarely relevant except for doing computation on the image data but not for representing the values itself. Thus, I'd like to have them outside the
GenericImagetrait but that somehow means reworking
Pixel(which has the concept of operations on value).
Vec<_>, the underlying storage of many buffer types, even for transparent wrappers. Hence, https://github.com/image-rs/canvas . The idea being that you can—in the future—imbue a strict, color space aware type onto the buffer content without any actual overhead. Then the buffer needs to care only about representation and color space information can be added by other traits.. But still a fairly long way, I think
&mut SubImage<RgbaImage>but should have been an
&mut SubImage<&mut RgbaImage>>
flat::FlatSamples, maybe that works how you'd like it to?
DynamicImage) expect to have full control over the layout of samples
imgrefdoesn't seem much more complex than the
SampleLayoutstructs to me, maybe some more initialization utilities for
SampleLayoutwould already help a lot?
webpis the container format and
vp8is the actual image data encoding (more information on Google's own page. While the PR mentioned works on decoding colors from
riffcontainer permits other data streams as well (EXIF metadata, animations, ..) and I don't think there is a plan to support these extensions.
DynamicImageis a bit of a mess that needs cleanup of its own
imageproc::drawing::draw_text(_mut)doesn't seem to work well with the dependencies
image v0.21or master branch of
imageprocworks fine). This issue has been fixed in master branch of
imageproc, I think.