Image: Split ImageBuffer and relevant low-level structs and traits for raw images into a separate crate?

[newpavlov]

It could be useful for using those structs in other crates which work with raw images and don't want to depend on whole image crate. Alternatively we could add additional default feature which will gate functionality not related to raw image representation.

[tomaka]

Alternatively we could add additional default feature which will gate functionality not related to raw image representation.

I would prefer this solution. Extracting crates and types into an external crate will likely cause semver hell in the long term.

[newpavlov]

But on the other hand separate crate will allow to stabilize it (lets call it image-core for now) earlier. Plus encoder/decoder crates will be able to depend on image-core, thus providing unified API, which will allow to move out shims which you currently have in image crate. As kind of prior art you can look at motivation behind rand_core split.

[fintelia]

I think we should give this some serious consideration. Right now the crates for specific image types (image-png, image-tiff, etc.) each have to implement their own versions of ColorType, ImageDecoder, and so forth which leads to a lot of redundancy.

[HeroicKatora]

I found another reason to support this option: There are two separate concerns at play here. The decoder part, and the image manipulation part. For web, such as in servo, the decoder part is much more focussed and should undergo extreme scrutiny. However, the focus of this library as is is far to large to generate complete 'input' coverage, as even the input term itself is extremely hard to define.

So, in the long term I think we should aim to narrow down the scope of several libs (bikeshedding names):

• image-core that only provides buffers and methods for pixel handling but no policy and also no interpretation of pixel values (no color spaces), no blending, etc. The best equivalent I can think of is the Linux DRM subsystem that only provides abstract byte buffers and common enumeration definitions in general afaik (ignoring the driver-supplied interface part).
• image which would re-export those for compat and integrate them with codecs/decoders, but excluding what is currently in crate::imageops. DynamicImage may be better left here than in image-core, to make is more likely for image-core to be possibly no-std and because of its auto converting mechanisms being technically policy. And here would be the extension point for color space conversion if we choose to do so.
• imageproc for operations on images.

That would give us the possibility of achieving a strong, and well tested foundation with image-core so that users who don't want to opt into the wider scope of auto conversion and operations can make use of decoders still.

[icefoxen]

I like this but I would suggest that the interpretation of pixel values be part of image-core. Pretty much every image format has its own enum for describing the options here and having them all be convertible into a single one would be a useful point of unification.

[fintelia]

@icefoxen Could you clarify what you mean by interpretation of pixel values? My current thinking is to have image-core include ColorType and ExtendedColorType but otherwise just operate on byte buffers. (Those types aren't yet available on master, but will be at some point).

[icefoxen]

Ah, sorry for being unclear. I was suggesting that image::ColorType be part of image-core. I thought that was what "no interpretation of pixel values" was referring to but now that I read it again I suppose it's referring to things like linear color vs sRGB.