HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ultralytics
yolov5
Python2020–2025
ultralytics / yolov5

yolov5

Ultralytics YOLOv5 in PyTorch for object detection, instance segmentation, classification, training, and export.

AI & Machine LearningCreative & MediaLearning & Reference
Explore on GitHubRead Hacker News discussions
15Distinct people
15Mentions
0Explicit recommenders
58.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Ultralytics YOLOv5 in PyTorch for object detection, instance segmentation, classification, training, and export.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year15 dated mentions

Observed mentions: 2020-06-10 17:21:30 UTC to 2025-05-02 15:12:16 UTC.

024682020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC808
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC312
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC110
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

What Hacker News says

15 sources
SansGuidon·May 2, 2025
I mostly focus on text based content so PDF and webpages are easily supported. for PDFs I thought about using https://github.com/phiresky/ripgrep-all or pdfgrep https://pdfgrep.org/ For images, what do you want to grep for? for exif data -> https://exiftool.org/ if you want to find image based content, you might need something smarter. I think maybe it is a place where tools such as https://github.com/ultralytics/yolov5 can shine for me. simple enough to work with most of my images and tag them according to some preferences, and I would save such tags in a txt file. Anyway, all metadata I store about images, links etc are all persisted in txt files. summaries, tags, etc, incoming/outgoing links etc, each has its own file. There are folders per link/content. Under each folder, one file per type of metadata. So it is very easy to know if so
Read the rest
me metadata is missing for a file, no index needed, it is just as simple as checking the presence of a file. everything is compatible with grep then. for docx and xlsx it is out of my plate at this time, I didn't experiment enough to judge what works well enough. I hate those things.
In Linkwarden: FOSS self-hostable bookmarking with AI-tagging and page archival
DonHopkins·Aug 18, 2024
Sometimes importing zombie "undead code" libraries can be beneficial! I just refactored a bunch of python computer vision code that used detectron2 and yolo (both of which indirectly use OpenCV and PyTorch and lots of other stuff), and in the process of cleaning up unused code, I threw out the old imports of the yolo modules that we weren't using any more. The yololess refactored code, which really didn't have any changes that should measurably affect the speed, ran a mortifying 10% slower, and I could not for the life of me figure out why! Benchmarking and comparing each version showed that the yololess version was spending a huge amount of time with multiple threads fighting over locks, which the yoloful code wasn't doing. But I hadn't changed anything relating to threads or locks in the refactoring -- I had just rearranged a few of the
Read the rest
deck chairs on the Titanic and removed the unused yolo import, which seemed like a perfectly safe innocuous thing to do. Finally after questioning all of my implicit assumptions and running some really fundamental sanity checks and reality tests, I discovered that the 10% slow-down in detectron2 was caused by NOT importing the yolo module that we were not actually using. So I went over the yolo code I was originally importing line by line, and finally ran across a helpfully commented top-level call to fix an obscure performance problem: https://github.com/ultralytics/yolov5/blob/master/utils/gene... cv2.setNumThreads(0) # prevent OpenCV from multithreading (incompatible with PyTorch DataLoader) Even though we weren't actually using yolo, just importing it, executing that one line of code fixed a terrible multithreading performance problem with OpenCV and PyTorch DataLoader fighting behind the scenes over locks, even if you never called yolo itself. So I copied that magical incantation into my own detectron2 initialization function (not as top level code that got executed on import of course), wrote some triumphantly snarky comments to explain why I was doing that, and the performance problems went away! The regression wasn't yolo's or detectron2's fault per se, just an obscure invisible interaction of other modules they were both using, but yolo shouldn't have been doing anything globally systemic like that immediately when you import it without actually initializing it. But then I would have never discovered a simple way to speed up detectron2 by 10%! So if you're using detectron2 without also importing yolo, make sure you set the number of cv2 threads to zero or you'll be wasting a lot of money.
In Micro-libraries should never be used
yeldarb·Jan 1, 2023
Haven't heard of those two, but would be really awesome to see an integration. We have an open API[1] for just this reason: we really want to make it easy to use (and source) your data across all the different tools out there. We've recently launched integrations with other labeling[2] and AutoML[3] tools (and have integrations with the big-cloud AutoML tools as well[4]). We're hoping to have a bunch more integrations with other developer tools, labeling services, and MLOps tools & platforms in 2023. Re synthetic data specifically, we've written a couple of how-to guides for creating data from context augmentation[5], Unity Perception[6], and Stable Diffusion[7] & are talking to some others as well; it seems like a natural integration point (and someplace where we don't need to reinvent the wheel). [1] https://docs.roboflow.com/rest-api [
Read the rest
2] https://github.com/SkalskiP/make-sense/pull/298 [3] https://github.com/ultralytics/yolov5/discussions/10425 [4] https://docs.roboflow.com/train/pro-third-party-training-int... [5] https://blog.roboflow.com/how-to-create-a-synthetic-dataset-... [6] https://blog.roboflow.com/unity-perception-synthetic-dataset... [7] https://blog.roboflow.com/synthetic-data-with-stable-diffusi...
In Roboflow 100: A New Object Detection Benchmark
CompleteSkeptic·Aug 4, 2020
This isn't directly relevant to PP-YOLO, but I'm surprised roboflow is still promoting "YOLOv5" - despite that model not having an associated paper and it not being made by the authors of the previous YOLO's.[1] The ML community has been asking the authors of that model to rename their project[2] because they are basically stealing publicity by making it seem like the next version of YOLO, despite its performance being worse than that of YOLOv4.[3] Roboflow has deflected this in the past by claiming they don't know if "YOLOv5" is the correct name[4], but by continuing to promote it, they are directly supporting it. In fact, I wouldn't be surprised that their claim of not being affiliated with Ultralytics to be either false or a half truth, given that all the top pages about "YOLOv5" were done by roboflow, including the first official anno
Read the rest
uncement.[5] [1] https://github.com/AlexeyAB/darknet/issues/5920 [2] https://github.com/ultralytics/yolov5/issues/2 [3] https://github.com/AlexeyAB/darknet/issues/5920#issuecomment... [4] https://blog.roboflow.ai/yolov4-versus-yolov5/ [5] https://blog.roboflow.ai/yolov5-is-here/
In PP-YOLO Surpasses YOLOv4 – State-of-the-art object detection techniques
voqv·Jun 14, 2020
Not that I really care, but the original GitHub issue[1] has multiple researchers "kicking up a fuss", why are you just reducing their opinion to "random opinionated commentators"? Also, the original creator did not say he does not care ("doesn't matter what I think"), he said another maintainer of darknet/yolo should have more say. [2] [1] https://github.com/ultralytics/yolov5/issues/2 [2] https://github.com/AlexeyAB/darknet/issues/5920
In Responding to the Controversy about YOLOv5
anthiras·Jun 11, 2020
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...
In YOLOv5: State-of-the-art object detection at 140 FPS
bArray·Jun 10, 2020
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
In YOLOv5: State-of-the-art object detection at 140 FPS
ely-s·Jun 10, 2020
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...
In YOLOv5: State-of-the-art object detection at 140 FPS

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.