YOLOv5: State-of-the-art object detection at 140 FPS

Yeah, they made the most popular PyTorch implementation of YOLOv3 as well so they're not entering out of the blue, though. https://github.com/ultralytics/yolov3

The author of YOLOv3 quit working on Computer Vision due to ethical concerns. YOLOv4, which built on his work in v3, was released by different authors last month. I'd expect more YOLOvX's from different authors in the future. https://twitter.com/pjreddie/status/1230524770350817280

sonofaragorn• 6 years ago

I'm a bit fascinated by this Ultralytics. It has super nice website but according to LinkedIn, I think it's just one guy who does consultancy.

The intriguing part is that he has also done research in particle physics (as Ulatrlytics) that has been published in Nature [1].

I had never seen anything like that.

[1] https://www.nature.com/articles/srep13945

rememberlenny• 6 years ago

Two interesting links from the article:

1. How to train YOLOv5: https://blog.roboflow.ai/how-to-train-yolov5-on-a-custom-dat...

2. Comparing various YOLO versions https://yolov5.com/

bcatanzaro2• 6 years ago

Why benchmark using 32-bit FP on a V100? That means it’s not using tensor cores, which is a shame since they were built for this purpose. There’s no reason not to benchmark using FP16 here.

joshvm9• 6 years ago

Not sure about the benchmark, but the code includes the option for mixed precision training via Apex/AMP.

bcatanzaro2• 6 years ago

If you click around enough you’ll see they benchmarked in 32-bit FP. Glad they have a mixed precision training option but I really think it’s a mistake in 2020 to do work related to efficient inference using 32-but FP.

The problem is that your conclusions aren’t independent of this choice. A different network might be far better in terms of accuracy/speed tradeoffs when evaluated at a lower precision. But there is no reason to use 32-but precision for inference, so this is just a big mistake.

hnarayanan• 6 years ago

What does it take to now use this name?

ulam2• 6 years ago

Just guts, i guess. You would also need to show some real performance improvement.

bonoboTP• 6 years ago

If it's not trademarked, perhaps not much? I think it's pretty misleading, but the fight for attention is on! Using an established brand in your title will get more clicks.

newen• 6 years ago

Yeah, it's pretty unethical. Looks like they just stole the name without any care. There doesn't seem to be any relationship between these guys and the original YOLO group.

0xcoffee• 6 years ago

Is it possible to run these models in the browser, something similar to tensorflow.js?

m00dy• 6 years ago

I would try convert to ONNX model and then try to infer with tensorflowjs.

osipov• 6 years ago

Just recently IBM announced with a loud PR move that the company is getting out of the face recognition business. Guess what? Wall Street doesn't want to keep subsidizing IBM's subpar face recognition technology when open source and Google solutions are pushing the state of the art.

ahelwer• 6 years ago

Not something to brag about. Facial recognition has very few applications outside of total surveillance. We should not respect those who lend it their time and effort.

monocasa2• 6 years ago

I thought the real focus on the bad actors at this point was on gait detection. Works in civil unrest situations where everyone covers their face.

Not the the difference matters that much.

jcims6• 6 years ago

Facial recognition has very few applications outside of total surveillance.

That's not really for you to decide, is it? You're absolutely free to have that opinion of course.

We should not respect those who lend it their time and effort.

Also your choice of course. Facial recognition is essentially a light integration of powerful underlying technologies. Should 'we' ostracize those working on machine learning, computer vision, network and distributed computing, etc?

ericd• 6 years ago

Being able to distinguish between people is pretty foundational to being able to personalize AI applications. If you wanted to make a smart home actually smart and not just full of inconvenient remote controlled appliances, this is pretty necessary.

There are obviously privacy concerns with this example, it’d ideally be fully on-prem.

sillysaurusx11• 6 years ago

We made a site that lets you collaboratively tag a bunch of images, called tagpls.com. For example, users decided to re-tag imagenet for fun: https://twitter.com/theshawwn/status/1262535747975868418

And the tags ended up being hilarious: https://pbs.twimg.com/media/EYXRzDAUwAMjXIG?format=jpg&name=...

(I'm particularly fond of https://i.imgur.com/ZMz2yUc.png)

The data is freely available via API: https://www.tagpls.com/tags/imagenet2012validation.json

It exports the data in yolo format (e.g. it has coordinates in yolo's [0..1] range), so it's straightforward to spit it out to disk and start a yolo training run on it.

Gwern recently used tagpls to train an anime hand detector model: https://www.reddit.com/r/AnimeResearch/comments/gmcdkw/help_...

People seem willing to tag things for free, mostly for the novelty of it.

The NSFW tags ended up being shockingly high quality, especially in certain niches: https://twitter.com/theshawwn/status/1270624312769130498

I don't think we could've paid human labelers to create tags that thorough or accurate.

All the tags for all experiments can be grabbed via https://www.tagpls.com/tags.json, so over time we hope the site will become more and more valuable to the ML community.

tagpls went from 50 users to 2,096 in the past three weeks. The database size also went from 200KB a few weeks ago to 1MB a week ago and 2MB today. I don't know why it's becoming popular, but it seems to be.

rocauc6• 6 years ago

I remember following this as it came out (and learning windshield wipers should be called "swipey bois")

Surprised and happy to hear you're seeing high labeling quality.

We'll re-host with credit on https://public.roboflow.ai What license is this?

sillysaurusx11• 6 years ago

Thanks! We've decided to license the data as CC-0. We'll add that to the footer.

We don't host any images directly – we merely serve a list of URLs (e.g. https://battle.shawwn.com/tfdne.txt). But any data served via the API endpoints is CC-0.

sillysaurusx11• 6 years ago

Well, that didn't take long – our API endpoint keeled over. Luckily, you can fetch all the data directly from firebase:

  # fetch raw tag data
  $ curl -fsSL https://experiments-573d7.firebaseio.com/results/.json > tags.json
  $ du -hs tags.json
  14M tags.json

  # fetch tag metadata (colors, remapping label names, possibly other stuff in the future)
  $ curl -fsSL https://experiments-573d7.firebaseio.com/user_meta/.json > tags_meta.json
  $ du -hs tags_meta.json
  376K tags_meta.json
  $ jq tags_meta.json

Note that's the raw unprocessed data (no yolo). To get info about all experiments, you can use this:

  curl -fsSL https://experiments-573d7.firebaseio.com/meta/.json | jq

I'm a bit worried about the bill. It's up to $50 and rising: https://imgur.com/ZgmXsWU almost entirely egress bandwidth. Be gentle with those `curl` statements. :)

(I think that's due to a poor architectural decision on my part, which is solvable, and not due to egress bandwidth via the API endpoint. But it's always fun to see a J curve in your bill... It's about $1 a day right now. https://imgur.com/4gUTLO7)

foota• 6 years ago

Can you set it up so that it's only available via cloud? I'm sure that would bother people, but is a better alternative to losing access or you going broke :)

zb1plus• 6 years ago

Perhaps you can mirror it to an s3 bucket or GH repo for people to CURL more easily?

sillysaurusx11• 6 years ago

Heh, $1 per day? Try $1k per day. https://imgur.com/duugqHK

knicholes2• 6 years ago

I need a dataset and tags for hair, face, neck, arms, left breast, right breast, nipple, torso. Any tips? I'm training a GAN, but I need to specifically segment the parts, as I don't want nipples in the middle of a face. I don't want to have to manually annotate 1,000 images

sillysaurusx11• 6 years ago

At the moment, the only experiments with enough data to be useful are e621-portraits (5,407 tags https://www.tagpls.com/exp?n=e621-portraits) and danbooru-e (344 tags https://www.tagpls.com/exp?n=danbooru2019-e) both of which are NSFW.

Those are also drawings/anime, not photos. We have an /r/pics experiment (SFW, 99 tags https://www.tagpls.com/exp?n=r-pics) and /r/gonewild (NSFW, 57 tags https://www.tagpls.com/exp?n=r-gonewild) but currently I haven't gathered enough urls to be very useful -- it only scrapes about 100 or so images every half hour. So there is a lack of tags right now on human photos. We also have a pps experiment (NSFW, exactly what you think it is, 306 tags https://www.tagpls.com/exp?n=pps) but I assume that's not quite what you were looking for.

If you have an idea for a dataset, you can create a list of image URLs like https://battle.shawwn.com/r/pics.txt and we can add them to the site. You can request an addition by joining our ML discord (https://discordapp.com/invite/x52Xz3y) and posting in the #tagging channel.

Also, if anyone's curious, here's how I'm measuring the tag count:

  $ curl -fsSL https://experiments-573d7.firebaseio.com/results/danbooru2019-e/.json | jq '.' | grep points | wc -l
       344
  $ curl -fsSL https://experiments-573d7.firebaseio.com/results/e621-portraits/.json | jq '.' | grep points | wc -l
      5407
  $ curl -fsSL https://experiments-573d7.firebaseio.com/results/r-gonewild/.json | jq '.' | grep points | wc -l
        57
  $ curl -fsSL https://experiments-573d7.firebaseio.com/results/r-pics/.json | jq '.' | grep points | wc -l
        99
  $ curl -fsSL https://experiments-573d7.firebaseio.com/results/pps/.json | jq '.' | grep points | wc -l
       306

jcun41283• 6 years ago

I don't want nipples in the middle of a face

There is a market somewhere

dang2• 6 years ago

You should post this as a Show HN!

sillysaurusx11• 6 years ago

Okay! Thank you. We appreciate the encouragement.

It looks like an HN user on an EC2 server decided to fetch data from our firebase as quickly as possible, running up a $3,700 bill. Once (or if) that's sorted out, and once we verify tagpls can handle HN's load without charging thousands of dollars, we'll add an "about" page to tagpls and submit it.

nerderloo4• 6 years ago

How does this have anything to do with the linked article?

sillysaurusx11• 6 years ago

The idea with the site is that you can tag your own datasets, and then get the data suitable for yolo training. We've done that ourselves to train an anime hand detector, and other users have reported similar successes. I could've been a bit clearer about that.

qchris• 6 years ago

If anyone's interested in the direct GitHub link to the repository: https://github.com/ultralytics/yolov5

travisporter• 6 years ago

Hm on this page it has something written in an eastern language under YOLO, https://github.com/ultralytics says Madrid, Spain, but then they say "Ultralytics is a U.S.-based particle physics and AI startup"

hikarudo• 6 years ago

"You only look once" in Chinese.

ely-s• 6 years ago

There seems to be an unfair comparison between the various network architectures. The reported speed and accuracy improvements should be taken with a bit of scepticism for two reasons.

* This is the first yolo implemented in Pytorch. Pytorch is the fastest ml framework around, so some of YOLOv5's speed improvements may be attributed to the platform it was implemented on rather than actual scientific advances. Previous yolos were implemented using darknet, and EfficientDet is implemented in TensorFlow. It would be necessary to train them all on the same platform for a fair speed comparison.

* EfficientDet was trained on the 90-class COCO challenge (1), while YOLOv5 was trained on 80 classes (2).

[1] https://github.com/ultralytics/yolov5/blob/master/data/coco....

[2] https://github.com/google/automl/blob/master/efficientdet/in...

rocauc6• 6 years ago

Great points, and hoping Glenn releases a paper to complement performance. We are also planning more rigorous benchmarking nonetheless.

re: PyTorch being a confounding factor for speed - we recompiled YOLOv4 to PyTorch to achieve 50 FPS. Darknet would likely top out around 10 FPS on the same hardware.

EDIT: Alexey, author of YOLOv4, provided benchmarks of YOLOv4 hitting much higher FPS here: https://github.com/AlexeyAB/darknet/issues/5920#issuecomment...

cgarciae• 6 years ago

Side note: I like Pytorch but eager pytorch is not faster the jax.jit or tf.function code

DEDLINE2• 6 years ago

Does anyone know of an open-source equivalent to YOLOv5 in the sound recognition / classification domain? Paid?

fattire• 6 years ago

Like it would identify what you're hearing? "Trumpet!" "Wind whistling through oak leaves!" "Male child!" etc?

DEDLINE2• 6 years ago

Ubicoustics [1] would be the closest example to what I am looking for in a FOSS / Commercial offering. Is anyone working on this?

[1] https://github.com/FIGLAB/ubicoustics

ebg13• 6 years ago

It looks like this is YOLOv4 implemented on PyTorch, not actually a new YOLO?

bArray8• 6 years ago

YOLO is a neural network, Darknet is the framework. Without both YOLOv4 and "YOLOv5" on the same framework, it makes it near impossible to make any kind of meaningful comparison.

franciscop• 6 years ago

I am very interested on loading YOLO into a Raspberry Pi + Coral.ai, anyone knows a good tutorial on how to get started? I tried before and with Darknet it was not easy at all, but now with pytorch there seem to be ways of loading that into Coral. I am familiar with Raspberry Pi dev, but not much with ML or TPUs, so I think it'd be mostly a tutorial on bridging the different technologies.

(might need to wait a couple of months since this was just released)

jcims6• 6 years ago

Has anyone (beyond maybe self-driving software) tried using object tagging as a way to start introducing physics into a scene? E.g. human and bicycle have same motion vector, increases likelihood that human is riding bicycle. Bicycle and human have size and weight ranges that could be used to plot trajectory. Bicycles riding in a straight line and trees both provide some cues as to the gravity vector in the scene. Etc. etc.

Seems like the camera motion is probably already solved with optical flow/photogrammetry stuff, but you might be able to use that to help scale the scene and start filtering your tagging based on geometric likelihood.

The idea of hierarchical reference frames (outlined a bit by Jeff Hawkins here https://www.youtube.com/watch?v=-EVqrDlAqYo&t=3025 ) seems pretty compelling to me for contextualizing scenes to gain comprehension. Particularly if you build a graph from those reference frames and situate models tuned to the type of object at the root of each each frame (vertex). You could use that to help each model learn, too. So if a bike model projects a 'riding' edge towards the 'person' model, there wouldn't likely be much learning. e.g. [Person]-(rides)->[Bike] would have likely been encountered already.

However if the [Bike] projects the (rides) edge towards the [Capuchin] sitting in the seat, the [Capuchin] model might learn that capuchins can (ride) and furthermore they can (ride) a [Bike].

craftinator• 6 years ago

I've been wondering these same thoughts for years. I don't do much work in the neural network subfield, but have done a lot with computer vision, and always found myself wanting more robust physical estimation techniques that didn't require external data.

joshvm9• 6 years ago

RGB-D based semantic segmentation is certainly a thing. I'm sure it's also been done with video sequences as well.

jcims6• 6 years ago

Yeah I wish the flagship phone manufacturers would put the hardware back into the phone to take 3d photos...even better if you can get point cloud data to go with it. The applications right now are kind of cheesy but they will get better and if the majority of photos taken pivot to including depth information i think it could really drive better capabilities from our phones.

Eyes are very hard to make and coordinate, yet there are almost no cyclops in nature.

david_draco• 6 years ago

In February 2020, PJ Reddie noted he would discontinue research in computer vision.

It would be fair to state also why he chose to discontinue developing YOLO, as it is relevant.

heavyset_go2• 6 years ago

I like to think that the name is also a reference to the fact that this will inevitably be used in some autonomous driving systems.

nharada• 6 years ago

I welcome forward progress in the field, but something about this doesn't sit right with me. The authors have an unpublished/unreviewed set of results and they're already co-opting the YOLO name (without the original author) for it and all of this to promote a company? I guess this was inevitable when there's so much money in ML but it definitely feels against the spirit of the academic research community that they're building upon.

syntaxing• 6 years ago

Totally agreed, kinda seems dirty to call something "v5" when it this is a derivative work of the original.

oehtXRwMkIs• 6 years ago

I think derivative is a bit generous. This is just a reimplementation of v4 with a different framework.

salty_biscuits• 6 years ago

Well, very unlikely to get the original author. He doesn't do that kind of thing anymore

https://twitter.com/pjreddie/status/1230524770350817280?s=19

sicariusnoctis• 6 years ago

there's so much money in ML

What do you mean? I thought the DL hypetrain was dying as companies failed to make returns on their investments.

bArray8• 6 years ago

I'm just going to call this out as bullshit. This isn't YOLOv5. I doubt they even did a proper comparison between their model and YOLOv4.

Someone asked it to not be called YOLOv5 and their response was just awful [1]. They also blew off a request to publish a blog/paper detailing the network [2].

I filed a ticket to get to the bottom of this with the creators of YOLOv4: https://github.com/AlexeyAB/darknet/issues/5920

[1] https://github.com/ultralytics/yolov5/issues/2

[2] https://github.com/ultralytics/yolov5/issues/4

rcpt• 6 years ago

I love that the response to them is "you can you up,no can no bb"

Learned a new phrase today.

catalogia• 6 years ago

Can you explain it? I can't figure out what that means.

whoevercares3• 6 years ago

你行你上啊不行别bb（bb=trashtalking/non-favorable comments）

This is literally trash talking Slang in Chinese, because this field is full of young bloated researchers who forget their last name

kuzee2• 6 years ago

Looks like ultralytics, not roboflow, is the one that named this model v5. Different people/companies.

bArray8• 6 years ago

Yep, I updated my GitHub comment with respect to what @josephofiowa said. I made an assumptions when seeing the same PR images/language being used.

sillysaurusx11• 6 years ago

There are some benchmarks here: https://github.com/WongKinYiu/CrossStagePartialNetworks/issu...

It's hard to interpret benchmarks in a fair way, but it's sort of sounding like YOLOv4 might be superior to YOLOv5, at least for certain resolutions.

Does YOLOv5 outperform YOLOv4 at all? Faster inference time or higher accuracy?

rocauc6• 6 years ago

Hey all - OP here. We're not affiliated with Ultralytics or the other researchers. We're a startup that enables developers to use computer vision without being machine learning experts, and we support a wide array of open source model architectures for teams to try on their data: https://models.roboflow.ai

Beyond that, we're just fans. We're amazed by how quickly the field is moving and we did some benchmarks that we thought other people might find as exciting as we did. I don't want to take a side in the naming controversy. Our core focus is helping developers get data into any model, regardless of its name!

sillysaurusx11• 6 years ago

YOLOv5 seems to have one important advantage over v4, which your post helped highlight:

Fourth, YOLOv5 is small. Specifically, a weights file for YOLOv5 is 27 megabytes. Our weights file for YOLOv4 (with Darknet architecture) is 244 megabytes. YOLOv5 is nearly 90 percent smaller than YOLOv4. This means YOLOv5 can be deployed to embedded devices much more easily.

Naming controversy aside, it's nice to have some model that can get close to the same accuracy at 10% of the size.

Naming it v5 was certainly ... bold ... though. If it can't outperform v4 in any scenario, is it really worthy of the name? (On the other hand, if v5 can beat v4 in inference time or accuracy, that should be highlighted somewhere.)

FWIW I doubt anyone who looks into this will think roboflow had anything to do with the current controversies. You just showed off what someone else made, which is both legit and helpful. It's not like you were the ones that named it v5.

On the other hand... visiting https://models.roboflow.ai/ does show YOLOv5 as "current SOTA", with some impressive-sounding results:

SIZE: YOLOv5 is about 88% smaller than YOLOv4 (27 MB vs 244 MB)

SPEED: YOLOv5 is about 180% faster than YOLOv4 (140 FPS vs 50 FPS)

ACCURACY: YOLOv5 is roughly as accurate as YOLOv4 on the same task (0.895 mAP vs 0.892 mAP)

Then it links to https://blog.roboflow.ai/yolov5-is-here/ but there doesn't seem to be any clear chart showing "here's v5 performance vs v4 performance under these conditions: x, y, z"

Out of curiosity, where did the "180% faster" and 0.895 mAP vs 0.892 mAP numbers come from? Is there some way to reproduce those measurements?

The benchmarks at https://github.com/WongKinYiu/CrossStagePartialNetworks/issu... seem to show different results, with v4 coming out ahead in both accuracy and speed at 736x736 res. I'm not sure if they're using a standard benchmarking script though.

Thanks for gathering together what's currently known. The field does move fast.

heyitsguay• 6 years ago

Very cool business model! How long have you been at it? I've been pushing for a while (unsuccessfully, so far) for the NIH to cultivate a team providing such a service to our many biomedical imaging labs. It seems pretty clear to me that this sort of AI hub model is going to win out in at least the medium term versus spending money on lots of small redundant AI teams each dedicated to a single project. What sort of application sectors have you found success with?

bArray8• 6 years ago

We're not affiliated with Ultralytics or the other
researchers.

Unfortunately I am now unable to edit to reflect this better.

anthiras• 6 years ago

It's about time for Roboflow to pull this article. It seems highly unlikely that a 90 % smaller model would provide a similar accuracy, and the result seems to come from a small custom dataset only. Please make a real COCO comparison instead.

The YoloV5 repo itself shows performance comparable to YoloV3: https://github.com/ultralytics/yolov5#pretrained-checkpoints

Another comparison suggests YoloV5 is slightly WORSE than YoloV4: https://github.com/WongKinYiu/CrossStagePartialNetworks/issu...

quietbritishjim• 6 years ago

Someone asked it to not be called YOLOv5 and their response was just awful [1]

I don't see any response by them at all. Do you mean the comment by WDNMD0-0? I can't see any reason to believe they're connected to the company, have I missed something?

joshvm9• 6 years ago

I somewhat agree on the naming issue. I don't think yolov5 is semantically very informative. But by the way, if you read the issues from a while back you'll see that AlexeyAB's fork basically scooped them, hence the version bump. Ultralytics probably would have called this Yolov4 otherwise. This repo has been in the works for a while.

For history, Ultralytics originally forked the core code from some other Pytorch implementation which was inference-only. Their claim to fame is that they were the first to get training to work in Pytorch. This took a while, probably because there is actually very little documentation for Yolov3 and there was confusion over what the loss function actually ought to be. The darknet repo is totally uncommented C with lots of single letter variable names. AlexeyAB is a Saint.

That said, should it be a totally new name? The changes are indeed relatively minor in terms of architecture, it's still yolo underneath (in fact I think the classification/regression head is pretty much unchanged). The v4 release was also quite contentious. Actually their previous models used to be called yolov3-spp-ultralytics.

Probably I would have gone with efficient-yolo or something similar. That's no worse than fast/faster rcnn.

I disagree on your second point though. Demanding a paper when the author says "we will later" is hardly a blow off. Publishing and writing takes time. The code is open source, the implementation is there. How many times does it happen the other way around? And before we knock Glenn for this, as far as I know, he's running a business, not a research group.

Disclosure: I've contributed (in minor ways) to both this repository and Alexey's darknet fork. I use both regularly for work and I would say I'm familiar enough with both codebases. I mostly ignore the benchmarks because performance on coco is meaningless for performance on custom data. I'm not affiliated with either group, in case it's not clear.

nerderloo4• 6 years ago

Didn't AlexeyAB endorse YOLOv4 though? Did he also endorse YOLOv5?

bArray8• 6 years ago

But by the way, if you read the issues from a while back
you'll see that AlexeyAB's fork basically scooped them,
hence the version bump.

Yeah that sucks, but it does mean they should have done some proper comparison with YOLOv4.

This took a while, probably because there is actually very
little documentation for Yolov3 and there was confusion
over what the loss function actually ought to be. The
darknet repo is totally uncommented C with lots of single
letter variable names. AlexeyAB is a Saint.

Maybe I'm alone, but I found it quite readable. You can quite reasonably understand the source in a day.

The v4 release was also quite contentious.

Kind of, I am personally still evaluating this network fully.

I disagree on your second point though. Demanding a paper
when the author says "we will later" is hardly a blow off.

Checkout the translation of "you can you up,no can no bb" (see other comments).

And before we knock Glenn for this, as far as I know, he's
running a business, not a research group.

I understand, but this seems very unethical to take the name of an open source framework and network that publishes it's improvements in some form, bump the version number and then claim it's faster without actually doing an apples to apples test. It would have seem appropriate to contact the person who carried the torch after pjreddie stepped down from the project.

boscon• 6 years ago

Latency is measured for batch=32 and divided by 32? This means that 1 batch will be processed in 500 milliseconds. I have never seen a more fake comparison.

ma2rten• 6 years ago

In February 2020, PJ Reddie noted he would discontinue research in computer vision.

He actually stopped working on it because of ethical concerns. I'm inspired that he made this principled choice despite being quite successful in this field.

https://syncedreview.com/2020/02/24/yolo-creator-says-he-sto...

kuzee2• 6 years ago

Just read this. Nice overview of the history of the "YOLO" family, and summary of what YOLOv5 is/does.

tapatio• 6 years ago

Less weights, more accuracy. Magic :)

heisenburgzero• 6 years ago

This is not the first time something is fishy. Back in the early stages of the repo. They were advertising on the front page that they are achieving similar MAP to the original C++ version. But only to be found out they haven't train it on COCO dataset and test it.

darknet-rider• 6 years ago

I really like the work done by AlexAB on darknet YOLOv4 and the original author Joseph Radmon with YOLOv3. These guys need a lot more respect than any other version of YOLO.

YOLOv5: State-of-the-art object detection at 140 FPS

Related Stories