Hi there,

Thank you for reaching out and providing detailed information about your issue. It looks like you're encountering a PermissionError when trying to read the image file with OpenCV on your Windows platform.

To help resolve this, please consider the following steps:

1. Verify File Path and Permissions: Ensure that the file path "E:\\coco_test_renamed" is correct and that the file exists. Also, check the file permissions to make sure your script has read access to this file.

2. Check File Path Format: Windows paths can sometimes be tricky. Try using raw strings or double backslashes to avoid escape character issues:

   image = cv2.imread(r"E:\coco_test_renamed")

3. Update Packages: Make sure you are using the latest versions of all relevant packages, including ultralytics, supervision, and opencv-python. You can update them using pip:

   pip install --upgrade ultralytics supervision opencv-python

4. Minimum Reproducible Example: If the issue persists, providing a minimum reproducible example can greatly help in diagnosing the problem. You can find guidance on creating one here: Minimum Reproducible Example Guide.

Here is a simplified version of your code to help isolate the issue:

import cv2

# Ensure the file path is correct and accessible
image_path = r"E:\coco_test_renamed"
image = cv2.imread(image_path)

if image is None:
    print(f"Failed to load image from {image_path}")
else:
    print("Image loaded successfully")

Run this snippet to check if the image loads correctly. If it doesn't, the issue is likely with the file path or permissions.

Please try these steps and let us know if the problem persists. We're here to help!

Hi Thank you very much for your help.

After testing and adjusting the source code, I found that the real problem is not file permissions, but def imread(filename: str, flags: int = cv2.IMREAD_COLOR) This function can only accept a single image as the input parameter, and I wrote the file path as the folder path instead of the image path when I entered the parameter, so I caused a Permissionerror: [errno 13] permission denied ERROR. It is true that we should not only see the surface of ERROR but also understand the underlying causes of ERROR.

Thanks again for your help!

@YaoEndless hi there,

Thank you for the update and for identifying the root cause of the issue! It's great to hear that you were able to pinpoint the problem with the file path.

Indeed, the cv2.imread function expects a path to a single image file, not a directory. It's a common mistake, and your experience will certainly help others who might encounter a similar issue.

If you have any further questions or run into other issues, feel free to reach out. We're here to help! For more detailed guidance on various topics, you can always refer to our Ultralytics Help page.

Happy coding! 😊

El pico de CPU suele venir principalmente de la ingesta/decodificación RTSP (FFmpeg/OpenCV), buffering y preprocesado por stream, no del forward en GPU; al abrir varios RTSP a la vez se multiplican esos hilos de decodificación y la CPU se convierte en el cuello de botella aunque la inferencia vaya en la RTX. Para mitigarlo, normalmente ayuda bajar FPS efectivo y resolución (p. ej. vid_stride + imgsz), usar modo multi-stream para procesar varios RTSP en un solo proceso, y asegurarte de iterar en streaming (generador) como en la guía de fuentes de inferencia (Stream y Multi-Stream); si además haces conteo con IDs, revisa Track mode porque el tracking añade carga extra.

Para 400 cámaras, casi siempre termina siendo una arquitectura distribuida (varios nodos) y dimensionada por “cámaras × FPS objetivo × resolución”: on‑prem cerca de las cámaras suele ser más viable por ancho de banda y latencia, y un enfoque híbrido (edge para inferir + cloud para eventos/métricas) suele escalar mejor; como referencia de decisiones/criterios, mira buenas prácticas de despliegue y el artículo sobre edge vs cloud para desplegar YOLO26. Si compartes resolución/codec (H.264/H.265), FPS de cámara, FPS objetivo por stream y el comando/código exacto que usas, puedo ayudarte a estimar capacidad por GPU y dónde se está yendo la CPU.

1. ¿Cuántas cámaras puede soportar mi arquitectura actual manteniendo un buen rendimiento y una precisión aceptable?
2. ¿Cuál sería la arquitectura ideal para desplegar entre 5 y 10 cámaras con una precisión cercana al 90%?

• GPU: NVIDIA RTX 4050 (6GB VRAM)
• RAM: 64 GB
• CPU: Intel Core i5 (12ª generación)
• Sistema operativo: Ubuntu Server

• Ingesta RTSP
• Inferencia con YOLO11n en GPU
• Tracking con ByteTrack
• Publicación vía MJPEG sobre HTTP

• Número estimado de cámaras que puede soportar una GPU bajo esta configuración.
• Si utilizar modo multi-stream en un solo proceso mejoraría significativamente la eficiencia frente al modelo actual de procesos independientes.
• Buenas prácticas para mantener una precisión cercana al 90% al escalar.
• Arquitectura recomendada para 5–10 cámaras con alta precisión.
• Arquitectura distribuida sugerida para un escenario de 100–150 cámaras.

Código Fuente

El código fuente y la implementación actual pueden consultarse en:

👉 https://github.com/Juanrp7/analiticam

La bajada de precisión casi siempre viene de que al recortar carga (p. ej., subir vid_stride y/o bajar FPS efectivo) el tracking se vuelve inestable: ByteTrack pierde asociaciones/IDs y los cruces de línea dejan de contarse bien, así que para llegar a 80–90% normalmente necesitas mantener más “densidad temporal” (más frames útiles) y recortar CPU por otro lado, idealmente usando el substream de la cámara (misma escena pero menor bitrate/resolución) y/o decodificación acelerada en lugar de saltarte tantos frames; también ayuda ajustar el YAML del tracker a tu escena (umbral de matching/buffer, etc.) partiendo de los configs en el directorio de trackers.

Sobre capacidad, con una RTX 4050 de 6GB el límite suele ser la ingesta/decodificación + tracking (y el MJPEG también consume CPU), no tanto la inferencia; si consigues decodificar “barato” y usas un modelo ligero (te recomendaría probar Ultralytics YOLO con yolo26n.pt/yolo26s.pt), 5–10 cámaras a 480p con FPS moderado suele ser alcanzable, pero la forma fiable de estimarlo es medir 1 cámara y escalar hasta saturar CPU/GPU (porque depende mucho de cuánta gente haya en escena y del codec H.265 vs H.264).

Si compartes en texto (sin HTML) el comando exacto y la parte mínima del pipeline de tu repo repositorio analiticam que reproduce el conteo, junto con la salida de yolo checks, podemos afinar el dimensionamiento y ver si tienes cuellos por múltiples instalaciones/rutas (guía útil: Troubleshooting Common YOLO Issues).

Glad you got it working — in PyCharm this is almost always the Run/Debug “Python interpreter” pointing to a different env than your terminal, so please double-check sys.executable and that ultralytics.__file__ resolves inside the same conda env/site-packages (and if it doesn’t, run ultralytics.utils.checks.check_multiple_install() to catch shadowed installs); the env-conflict patterns are also covered in the Troubleshooting Common YOLO Issues guide.

import sys, ultralytics
print(sys.executable)
print(ultralytics.__version__)
print(ultralytics.__file__)

This usually means a version/path mismatch: the yolo26m-seg.pt checkpoint was saved with a build that includes Segment26, but the ultralytics you’re importing in that conda env doesn’t (or you have multiple installs shadowing each other), so please upgrade, restart Python, then paste the text output from yolo checks and the full traceback if it still fails (see the Troubleshooting Common YOLO Issues guide for common env conflicts).

pip install -U ultralytics
yolo checks

import ultralytics
print(ultralytics.__version__)
print(ultralytics.__file__)

Those BatchNorm2d settings (eps=1e-3, momentum=0.03) are a long-standing YOLO training convention rather than a random tweak: the slightly larger eps is mainly for numerical stability (especially with mixed precision and aggressive augmentations), and the lower momentum makes the running mean/var update more smoothly (less noisy), which can help robustness when batch composition varies. In practice they rarely “unlock” big mAP gains by themselves, but they tend to reduce edge-case instability and keep training behavior consistent across YOLO models; see the background in our Batch Normalization overview.

Thank you for your reply. Wish you a wonderful day!

I have found a way by modifying the pyproject.toml and executing pipx install.

@elsaoreen if you’ve already exported to NCNN, you can load the exported *_ncnn_model folder with YOLO(...) and pass Picamera2 frames (as np.ndarray) directly; see the NCNN integration guide for the expected export/load workflow.

from picamera2 import Picamera2
import cv2
from ultralytics import YOLO

model = YOLO("yolo26n_ncnn_model")  # path to exported NCNN model folder

picam2 = Picamera2()
picam2.configure(picam2.create_preview_configuration(main={"format": "RGB888"}))
picam2.start()

while True:
    frame = picam2.capture_array()                  # RGB
    frame = cv2.cvtColor(frame, cv2.COLOR_RGB2BGR)  # Ultralytics/OpenCV-friendly
    _ = model.predict(source=frame, imgsz=640, conf=0.25, verbose=False)

@keykin matplotlib is currently a required dependency in ultralytics, so “no-matplotlib” installs aren’t officially supported, but if you want to avoid editing pyproject.toml, pipx can pass through --no-deps via --pip-args and then you can selectively add packages with pipx inject (see pipx install docs and the pipx inject examples).

pipx install ultralytics --pip-args="--no-deps"
pipx inject ultralytics numpy opencv-python pillow pyyaml requests scipy

[1, 6, 8400] 里这个 6 通常不是“只有 1 个类别”，而是 4 + nc：前 4 个通道是框坐标，后 nc 个通道是每个类别的分数；所以当 6=4+2 时，恰好表示你的模型是 2 类（与你的 pt 一致），只是导出后的张量结构里没有单独的 objectness 通道（端到端/NMS-free 头一般用 per-class score 形式）。相关输出说明见导出模型的输出张量说明。如果你愿意，把你的导出命令（是否带了 nms=True）和 ONNX 的输出节点名贴在这里，我可以帮你对齐后处理的维度/转置方式。