Inscruitable error message from imageproc: Trait bounds error

This is using imageproc crate version 0.25. I moved from v0.23, where I was not having these problems

draw_filled_rect fails in the new version

fn example1(input: &mut RgbImage, top: u32, poa:&PoAWorkQueueData, ){
    let legend_rect: Rect = Rect::at(0, 0).of_size(10, 10);
    drawing::draw_filled_rect_mut(input, legend_rect, Rgb([255, 255, 255]));   
}

input was created

Clippy gives the following output:

‘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

As far as I can tell I am following the example from GitHub - image-rs/imageproc: Image processing operations examples/drawing.rs exactly.

I am expecting I am using the incorrect type for input, but I cannot work out what type I should be using.

Are you sure you're not using two versions of the image crate now? Try cargo tree --duplicates.

2 Likes

I did not know that was possible.

Yes I am.

gif v0.12.0
└── image v0.24.8 (*)

gif v0.13.1
└── image v0.25.2 (*)

How do I fix that?

I am going to try using cargo tree to track down the root of the dependencies of the differing versions and update them to the latest.

Is that a sensible, efficient approach?

And how could you tell from looking at that error message? I want to be able to help myself!

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.

1 Like

That was the problem

I updated imageptoc to get draw_antialiased_polygon and did not update img

Sigh

Thank you for your attention and your help

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.