Hi, I’m just questioning myself is VF2 a good SBC for OpenCV use-case, the camera subsystem is ok, just checked it with IMX219. But…
If I get this right, JH7110 cores have no vector instructions support, so probably VF2 is not really good at it.
Your opinions?
The GPU is pretty powerful in the VF2, you might be able to offload processing to it. I honestly do not know.
The only currently available RISC-V chip I know with vectors is the Allwinner D1 and it is probably a bad choice, because they used a draft for their vectors, so it is only supported by their own binary tool chain.
As for if the VF2 is a good SBC for OpenCV, I guess it depends on the problem space.
3 Likes
I totally agree with your punchline. (Not surprising since you’re citing my post.) The V story is just a mess right now.
Things have changed every-so-slightly since writing that in Sep-2022, though. It remains true that the only production core that’s shipping with RVV (non-standard pre-release) is the T-Head C906, which is used in the D1 and D1s. Since that post, the C906 has shipped in the Bouffalo Labs BL808 chip, as found in the $10-ish Ox64 and M1S Dock so that same level of V (0.7.10is there. If you’re experimenting with OpenCV that’s probably the least expensive way to run Vector on real hardware. We’re probably a low number of months from seeing the TH-1520 which will give us our first mainstream OOO RISC-V, finally passing Pi-4 level of performance, but it STILL is going to use the 0.7.1 Vector spec.
If you want to learn/experiment iwth real vector 1.0, don’t underestimate the You are correct that 7110 has no Vector unit. However, four 1.5Ghz cores (though they’re in-order) are nothing to be sneezed at. OpenCV has specializations for RISC-V so it shouldn’t be a total bust.
The GPU is allegedly powerful, but we haven’t seen enough specs yet to know how to code to it.
MZS’s conclusion is spot-on. VF2 has a nice roomy general purpose Linux-y chip that can surely run some OpenCV. If you need transforms on a thousand BR-quality frames per second, this is probably not your starting point. If you’re “just” doing facial recognition or object identification or such, that’s easily done on $4 boards these days.
2 Likes
Thanks guys for the feedback, for now I’m “just doing” some facial recognition and object detection.
I’ve got an old-but-unused rock pi 4b, orange pi 5 with weird camera connectors and starfive 2 to start with. So these boards are pretty much on par in terms of opencv performance, right? So what matters is CPU cores number and frequency, If we keep GPU acceleration out of scope?
EDIT: just tried to install python3-opencv and on latest debian image it fails with:
libopencv-imgcodecs4.5d : Depends: libgdal30 (>= 2.3.1) but it is not installable
The only libgal available is libgdal31, if somebody knows how to solve this please post.
1 Like
some facial recognition and object detection.
At reasonable (15-30fps) from a common webcam-class camera? You should be in the game.
Even with scalar data and the GPU in park, Opi5 should “win”, having double the cores and being out of order. JH-7110 is a chip for early adopters to get software and early adoption boards and products really ramped, but it’s still like a 2018-ish design at heart. That’s pretty big for opening the RISC-V door but it just doesn’t have ARM/Pi levels of funding, shipment volumes, and experience. There’s not a hidden “Pi Killer” story waiting to be told; this is a product that’s finally good enough for large software to be built and debugged natively at a low cost.
Sounds like you have realistic expectations now. I’m interested in seeing any measurements or comparisons you’re able to make.
Just as a weird footnote for Vision Five trivia buffs, there actually WAS an AI engine which offered some independent vector style numeric operations, on the JH-7100 for V5r1, but it was dropped in V5r2’s JH-7110. I can’t remember if it was documented well enough for anyone to really take advantage of it. (I didn’t…) It was Nvidia based so it might have just been external doc. 芯片 It’s not clear if 7100 has a continued feature now that 7110 exists.
Welcome to interesting times!
Edit for your edit. I’m surprised there’s a dependency on GDAL for this. It seems unlikely that facial recognition NEEDS geospatial data abstraction layer. If you can’t find some option to ignore that or override it or something, you may have to build the whole shebang from source, disabling packages that haven’t been ported yet that you don’t need.
3 Likes
I’d go with opi5 if it wasn’t that proprietary cam connector and no adapter existing on the market. I’ve got a machine vision monochrome sensor with global shutter, it has standard rpi 15p ribbon, so I’ll try my luck with VF2 first though it’ll require some DTS and driver coping.
Strange dependency indeed, well let it be hard way.
You’d think in a Pi competitor that you wouldn’t have to explain that proprietary connections are bad. Sheesh.
You might also be able to distro-shop and find an OS (Fedora vs. Ubuntu vs. Arch or whatever) and land on a combination of packages that’s non-broken. Until the distros get build from everything upstreamed, the packaging situation is going to be pretty messy. Given how fragile installations are on VF5 are, that may be a losing strategy, too, but there are multiple strategies available to you.
Re: GDAL. I did a comic-strip style double take because it’s a somewhat esoteric library … that I happen to have code in. 
I’ve never seen it used outside the Geo universe. I suppose it’s vaguely possible that something uses GDAL to reproject an image across spherical models to compensate for camera lens distortion or something, but I had to dig really deep to come up with that excuseexplanation. {shrug}
2 Likes
Hi, I am doing a project which requires VF2 to read input from a USB camera (webcam) and detect an object from the image using YOLOv5 custom-trained object detection model. According to yolov5/requirements.txt at master · ultralytics/yolov5 · GitHub, I need OpenCV.
However, I failed to install OpenCV via “pip install opencv-python”. I also failed installing it from source referring to the instructions here: OpenCV: Installation in Linux
is there any solution to this? Thanks in advance.
I followed the instructions OpenCV: Installation in Linux again but with additional steps “apt install libgtk2.0-dev pkg-config” before cmake.
Also, under the cmake command should include “-DOPENCV_GENERATE_PKGCONFIG=YES” and “-DWITH_GTK=ON”
To test if OpenCV is successfully installed, I tried VideoCapture() in C++ with my Logitech C310. It works fine.
4 Likes