nocargo VS opencv-rust

If you want to iterate with nix instead of cargo, crate2nix and cargo2nix provides more caching and more fine control over your dependencies. I haven't used these two so you would have to decide for yourself. You may also want to try out nocargo for something more experimental.

Thank you. It looks very useful, so I’ll give it a try. Do you know, offhand, whether I can use crane to build a dependency specified in Cargo.toml with extra settings? I have a more complicated Rust application I’m trying to build with Nix. The solution I’ve arrived at for the moment is building with nocargo just so I can override OUT_DIR when building opencv, but it doesn’t work with LTO and the end result is inferior to my starting point. (If there’s a way to customize the opencv build without needing any extra packages, I’d love to hear about that too.)

https://github.com/twistedfall/opencv-rust makes it evident that they do try to support using a prebuild system-opencv. Maybe it is not correctly recognized?

opencv

The de facto solution for smart image processing is to use a computer vision library, such as opencv, which has experimental rust bindings: https://github.com/twistedfall/opencv-rust

There is an OpenCV bindings crate. This example might be what you're after https://github.com/twistedfall/opencv-rust/blob/master/examples/video_capture.rs

For example, this is the build script of the opencv bindings: https://github.com/twistedfall/opencv-rust/blob/master/build.rs

I’m trying to get around a known build issue—it would be great for it to be fixed upstream, but I don’t have any control over it except for setting OUT_DIR during its compilation.

I've been using https://github.com/twistedfall/opencv-rust a lot lately and it's really fantastic, they've done a great job matching up with how C++ works, so there are definitely good examples out there.

I never tried it, but the OpenCV bindings might work.

I thought it was going to be unsafe because of how Mat is implemented (more information here). ... I tested it and it should be fine memory-wise. My thought was that the code below was going to be allowed to compile.