Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Introduction to YOLO26

blog.roboflow.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: An Introduction to YOLO26

#31

Post by krapht »

MrGLaDOS wrote: post #30
yeldarb wrote: post #29

It’s a big improvement if you’re already paying them but, given their aggressive approach to licensing, I can’t imagine why anyone would choose to use an Ultralytics model on a new project in 2026. You’re just asking to be shaken down and have to pay off a large bill down the line. RF-DETR is both faster and more accurate and truly open source with an Apache 2.0 license: https://github.com/roboflow/rf-detr Full discl…

“RF-DETR is both faster and more accurate and truly open source with an Apache 2.0 license” Misleading marketing statement. The catch is that for image resolutions >=700x700pixels (most production usecases), the roboflow license is actually PML1.0 instead of Apache2.0 https://github.com/roboflow/rf-detr#license

> The catch is that for image resolutions >=700x700pixels (most production usecases)

Citation needed? 2XL looks like you go up to 800x800 pixel inputs. This isn't the dealbreaker you say it is - all pipelines benefit from thoughtful crop and rescaling before going to inference.

Re: An Introduction to YOLO26

#32

Post by Joel_Mckay »

maelito wrote: post #22

Can it measure the speed of a car on a video ?

Global-shutter cameras are fast and expensive, while Doppler radar modules are robust and under $30 these days.

Running machine-vision outside in the Sun or Weather can get tricky. There is also a limited supply of BS a firm can shovel before some bystander ends up dead. =3

https://www.bbc.co.uk/news/articles/c07yp02mxyjo

Re: An Introduction to YOLO26

#33

Post by MrGLaDOS »

krapht wrote: post #31
MrGLaDOS wrote: post #30

Earlier quoted context omitted.

“RF-DETR is both faster and more accurate and truly open source with an Apache 2.0 license” Misleading marketing statement. The catch is that for image resolutions >=700x700pixels (most production usecases), the roboflow license is actually PML1.0 instead of Apache2.0 https://github.com/roboflow/rf-detr#license

> The catch is that for image resolutions >=700x700pixels (most production usecases) Citation needed? 2XL looks like you go up to 800x800 pixel inputs. This isn't the dealbreaker you say it is - all pipelines benefit from thoughtful crop and rescaling before going to inference.

See the url in my comment (search for the term rfdetr-2xlarge). 2XL does indeed go up to 800x800 and has PML1.0 license instead of apache 2.0.

Rescaling is fine for some purposes but but not for all. For many domain-specific (often less common and odd dimensioned) objects, downscaling will severely reduce recall. There is a reason that Roboflow slaps a license that is not open source on those specific architectures.

In some cases tiled inferencing (for example with https://github.com/obss/sahi ) might do the job.

Re: An Introduction to YOLO26

#34

Post by [deleted] »

yeldarb wrote: post #29

It’s a big improvement if you’re already paying them but, given their aggressive approach to licensing, I can’t imagine why anyone would choose to use an Ultralytics model on a new project in 2026. You’re just asking to be shaken down and have to pay off a large bill down the line. RF-DETR is both faster and more accurate and truly open source with an Apache 2.0 license: https://github.com/roboflow/rf-detr Full discl…

[deleted]

Re: An Introduction to YOLO26

#35

Post by yeldarb »

MrGLaDOS wrote: post #30
yeldarb wrote: post #29

It’s a big improvement if you’re already paying them but, given their aggressive approach to licensing, I can’t imagine why anyone would choose to use an Ultralytics model on a new project in 2026. You’re just asking to be shaken down and have to pay off a large bill down the line. RF-DETR is both faster and more accurate and truly open source with an Apache 2.0 license: https://github.com/roboflow/rf-detr Full discl…

“RF-DETR is both faster and more accurate and truly open source with an Apache 2.0 license” Misleading marketing statement. The catch is that for image resolutions >=700x700pixels (most production usecases), the roboflow license is actually PML1.0 instead of Apache2.0 https://github.com/roboflow/rf-detr#license

That may be true for legacy CNNs but very few production use-cases require such a large resolution with DETRs. The latency scales quadratically with the resolution.

Regardless, you can do whatever resolution you want with the Apache 2.0 model. Just change the config at runtime; it was trained to be resolution agnostic.

You are correct that we also released larger models with a larger backbone under a different, non open-source license.

Re: An Introduction to YOLO26

#36

Post by Tepix »

GL26 wrote: post #19
Tepix wrote: post #6

With some previous versions of YOLO I‘ve found pages that run it in real-time locally on your browser, analyzing the webcam. Is there a demo like that available for YOLO26?

https://github.com/computer-vision-with-marco/realtime-detec...

Thanks. Is the result deployed anywhere?

Re: An Introduction to YOLO26

#37

Post by maelito »

MaxikCZ wrote: post #24
maelito wrote: post #22

Can it measure the speed of a car on a video ?

Same question, same answer: In pixels/second? Sure! What are you trying to accomplish by those questions? Are you genuinely asking, or just baiting? If the former, didnt answers to your previous question make it clear that your question makes less sense than you might assume?

It's a serious question. I took a few hours to try this range of models to do this task. Online guides recommend to calibrate the size of the image with a "horizon" line and its real physical size. That's quite complicated.

I wish new models coupled with LLM would be capable of estimating the size of features on the map, e.g. the size of the car in meters, to be able to derive the speed with a world understanding. But I have found no resource doing this.

Re: An Introduction to YOLO26

#38

Post by yeldarb »

MrGLaDOS wrote: post #33
krapht wrote: post #31

Earlier quoted context omitted.

> The catch is that for image resolutions >=700x700pixels (most production usecases) Citation needed? 2XL looks like you go up to 800x800 pixel inputs. This isn't the dealbreaker you say it is - all pipelines benefit from thoughtful crop and rescaling before going to inference.

See the url in my comment (search for the term rfdetr-2xlarge). 2XL does indeed go up to 800x800 and has PML1.0 license instead of apache 2.0. Rescaling is fine for some purposes but but not for all. For many domain-specific (often less common and odd dimensioned) objects, downscaling will severely reduce recall. There is a reason that Roboflow slaps a license that is not open source on those specific architectures.…

> See the url in my comment (search for the term rfdetr-2xlarge). 2XL does indeed go up to 800x800 and has PML1.0 license instead of apache 2.0.

All of the models, including the Apache 2.0 ones, can be configured to go higher than 800x800. The difference between the ones with the PML license and the Apache 2.0 ones is the backbone, not the resolution.

I'd suggest you read the ICLR paper[1] which shows clearly the difference between the backbones at various latencies in Figure 1.

> For many domain-specific (often less common and odd dimensioned) objects, downscaling will severely reduce recall.

We released an entire paper[2] at Neurips about the long-tail transferability of models across a multitude of domains and benchmarked RF-DETR against that benchmark. The Apache 2.0 model is pareto optimal over the larger PML model at latencies less than the XL size.

(I'm one of the co-founders of Roboflow and worked on RF-DETR and RF100-VL.)

[1] https://arxiv.org/abs/2511.09554 [2] https://arxiv.org/abs/2505.20612

Post reply on HN