‘input’: the trait bound `image::ImageBuffer<image::Rgb<u8>, Vec<u8>>: Canvas` is not satisfied
the trait `Canvas` is implemented for `Blend<I>`
required for `image::ImageBuffer<image::Rgb<u8>, Vec<u8>>` to implement `Canvas` [E0277]
‘drawing::draw_fille…’: the trait bound `image::ImageBuffer<image::Rgb<u8>, Vec<u8>>: imageproc::image::GenericImageView` is not satisfied
the following other types implement trait `imageproc::image::GenericImageView`:
image::image::SubImageInner<I>
imageproc::image::DynamicImage
imageproc::image::ImageBuffer<P, Container>
imageproc::image::flat::View<Buffer, P>
imageproc::image::flat::ViewMut<Buffer, P> [E0277]
‘drawing::draw_fille…’: the trait bound `image::ImageBuffer<image::Rgb<u8>, Vec<u8>>: imageproc::image::GenericImage` is not satisfied
the following other types implement trait `imageproc::image::GenericImage`:
image::image::SubImageInner<I>
imageproc::image::DynamicImage
imageproc::image::ImageBuffer<P, Container>
imageproc::image::flat::ViewMut<Buffer, P>
required for `image::ImageBuffer<image::Rgb<u8>, Vec<u8>>` to implement `Canvas` [E0277]
I have no idea what this error message is telling me (I feel I should), except that I am doing it wrong
They have to be SemVer incompatible, meaning their greatest non-0 components need to be different. But if that happens, yes, you can have two different versions which are considered two distinct crates. So a RgbImage from one won't implement traits from the other (unless via a blanket implementation that happens to apply).
I don't know a better way (but maybe someone else does).
My process went something like
Pull up imageproc on docs.rs and compare the methods across versions
No change
Compare the listed Canvas implementors
No change
Compare the GenericImage trait across image versions similarly
No change
Gradually while doing the above, get annoyed at error messages about imageproc::image::... and sanity check that imageproc publicly reexports image in their root
They do
Have a flash of inspiration that image and imageproc::image may actually be two different crates
Probably someone who has seen this more would have made the leap quicker (especially if familiar enough with the crates to realize the trait error was nonsensical, i.e. of course that type implements that trait regardless of version).
I'm generally annoyed by public reexports of dep crates due to multiplying the paths that can show up in error messages. But it happened to be a clue here. On the other hand, I don't think that it's a reliable clue... you may get messages about both image:: and imageproc::image:: even when you don't have duplicate deps.