Open newpavlov opened 6 years ago
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.
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.
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.
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.
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.
@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).
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.
A couple years late, but I should probably provide an update on this...
I tried working on this issue. Created a repository for image-core
, started copying over the relevant types, and was getting ready to release an initial 0.1 release. However, in the meantime we did the image 0.23.0 release which included some breaking changes to ImageDecoder
, ColorType
, and so forth. That made me take step back and think through what the process would be for doing breaking changes if these types had already been moved to the image-core
crate. It would be considerably more disruptive: the main image
crate and every single decoder that implemented traits from image-core
would have to make their own breaking releases in lockstep!
Without the ability to rapidly iterate on the types/traits, I didn't see how image-core
would be able to reach stability any faster than having the types in the main image
crate. Thus, I stopped working on the image-core
transition and redirected my focus to other aspects of the crate.
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.