First, I’m assuming that the patching is done to make PJ Reddies’s darknet-yolov3 to work with it. There was about a 15% performance loss with 8.0. I saw mention of some bug fixes, is one of them restoring the performance hit that darknet saw ?
Well… with the original darknet from PJ Reddie I thought that the newer CUDNN didn’t compile without a patch. I tried the patch a long time ago when it first came out but then darknet didn’t start properly. I think it ran out of memory. At this stage I’m not sure which patch is the correct one to fix compilation of the original PJ Reddie darknet code in order to test that.
Do you have any idea what the latest recommended patch is to the original PJ Reddie code is in order to get it to compile correctly on cuDNN 8.0 ? If so, I can re-test.
But it loads really slowing and then dies before finishing with:
67 conv 1024 3 x 3 / 1 19 x 19 x 512 → 19 x 19 x1024 3.407 BFLOPs
68 res 65 19 x 19 x1024 → 19 x 19 x1024
69 conv 512 1 x 1 / 1 19 x 19 x1024 → 19 x 19 x 512 0.379 BFLOPs
70 conv 1024 3 x 3 / 1 19 x 19 x 512 → 19 x 19 x1024 3.407 BFLOPs
71 res 68 19 x 19 x1024 → 19 x 19 x1024
72 conv 512 1 x 1 / 1 19 x 19 x1024 → 19 x 19 x 512 0.379 BFLOPs
73 conv 1024 3 x 3 / 1 19 x 19 x 512 → 19 x 19 x1024 3.407 BFLOPs
74 res 71 19 x 19 x1024 → 19 x 19 x1024
75 conv 512 1 x 1 / 1 19 x 19 x1024 → 19 x 19 x 512 0.379 BFLOPs
76 Killed
Excellent! My new project to connect YOLO implementations to useful preventative security on jetson platforms is getting closer to release I hope it will be useful to a lot of people. I’m getting excited, but there’s still a little work left.
In the meantime, it will support using AlexeyAB’s version of yolov3 and yolov3 as well as PJReddie’s implementation of yolov3. Strangely, with identical model and weight’s, in my testing, the classifications of yolov3 between AlexeyAB’s implementation and PJReddie’s are very different. In my testing over the last two years of detecting humans for security purposes’s PJReddies implementation generated less false positives that yolov4.
So there are likely still usecases where this is very important and despite the slow down people may choose for PJReddie’s implementation sometimes, despite the slowdown but then fixing the CUDNN implemation for this code would really be appreciated I think.
We didn’t notice the accuracy issue between these two repository.
It seems lots of our user switch to AlexeyAB version after cuDNNv8 release for the update.
We are still working on the YOLOv3 issue. Hope to give you a feedback soon.
Thanks thats great. It’s understandable that people switch as the accuracy was better. However, that should be put into context and into perspective if your goal is to detect people for security purposes with low false positives. For example (anecdotally from a low number of tests), when analysing one of my false positives using YOLOV4 I notices that yolov4 correctly detected many more flower pots in an image than yolov3 PJ Reddie detected. That will help improve the overall score of YOLOV4 but not in a manner that is relative to people detection for security. Again anecdotally it appears that YOLOV4 is a little more eager to see things and as such this results in correctly seeing more objects (Perhaps non-people objects) than PJ Reddie YOLOV3, which all goes to increase it’s accuracy. It’s possible that this behavior results in more correct matches of small people images as well (i.e. people far away), which increases the overal score.
However, if I had to choose to get twice as many correct matches of people far away that would normally be missed against getting a few extra false positives close up. For security I would choose to get less false positives close up as far away is less of a threat but false positives really mess up the whole process of monitoring.
I hope my explanation make’s sense. It’s really an attempt to say that overall accuracy score is not the only thing that matters when choosing an algorithm for security and why the PJ Reddie algorithm is still very relevant in the security field.
In my up coming software release I’ll be allowing the user to choose one of three algorithms so they can choose (And test) for themselves which suites them better. In short, if the view of view is non-cluttered and doesn’t contain much noise that can trigger false positives, then it’s quite viable to choose for the faster algorithm. In very cluttered environments, where you do not want to make too many exclusion zones, then choosing the algorithm with a lower incidence of false positives is likely a better choice.
It’s too much variation with what I’m trying to do at the moment. Plus I have not done anything with DeepStream yet so there will be a learning curve. For people using the yolov4 model it won’t affect them. For the other eventual uses there will just be a slight performance cost at the moment but it will still work.
I am also implementing the YOLO V3 by pjreddie and encountering the same OOM issue when cudnn >v8 is enabled. This fix would be greatly appreciated. Are there any updates on this?
Do you know if your python bindings are compatible with this approach? The websocket server will receive the images and then need to pass it to your stream for processing and then have the control return back to the websocket server handler. It’s conceivable that async python handling in your bindings are not compatible with another approach to asynchronous processing, I don’t know.