Respuesta rápida: ¿COCO, YOLO o Pascal VOC?
Si solo necesita una decisión práctica, puede usar esta regla general:
- Use COCO cuando el proyecto requiera anotaciones enriquecidas: detección de objetos, segmentación de instancias, puntos clave, máscaras, atributos o una estructura JSON a nivel de conjunto de datos que pueda respaldar varios experimentos de modelos.
- Use YOLO cuando la prioridad sea entrenar modelos de detección de objetos con rapidez, trabajar con conjuntos de datos ligeros y mantener compatibilidad directa con flujos de trabajo YOLO modernos.
- Use Pascal VOC cuando trabaje con flujos de trabajo heredados basados en XML, modelos de detección antiguos o canalizaciones empresariales que todavía esperan un archivo XML por imagen.
- Use otro formato cuando la tarea sea más especializada: conducción autónoma, segmentación panóptica, imagen médica, imágenes satelitales o una canalización de producción personalizada.
El mejor formato de anotación no es necesariamente el más popular. Es el que se ajusta a la arquitectura del modelo, la geometría de anotación, el framework de entrenamiento, el flujo de control de calidad y las necesidades futuras de conversión. Si el equipo todavía está definiendo la propia tarea de etiquetado, conviene empezar por los fundamentos de qué es la anotación de imágenes antes de fijar el esquema de exportación.
Por qué el formato de anotación importa antes del entrenamiento del modelo
El formato de anotación suele tratarse como un detalle técnico, pero puede afectar a toda la canalización de visión artificial. Un conjunto de datos puede estar correctamente etiquetado y aun así ser difícil de entrenar si el formato de exportación no coincide con el esquema esperado, el sistema de coordenadas, el mapeo de clases o la representación de segmentación. En proyectos externalizados, el formato debe definirse junto con la taxonomía, las reglas de control de calidad y las expectativas de entrega dentro del alcance del flujo de trabajo de los servicios de anotación de imágenes.
La elección del formato influye en:
- Compatibilidad del modelo: YOLO, Detectron2, MMDetection, TensorFlow Object Detection y las canalizaciones personalizadas en PyTorch no esperan todas la misma estructura de entrada.
- Geometría de anotación: algunos formatos están optimizados para cajas delimitadoras, mientras que otros admiten polígonos, máscaras, puntos clave, atributos o ID de instancia.
- Gestión del conjunto de datos: COCO almacena metadatos a nivel de conjunto de datos en JSON, mientras que YOLO y Pascal VOC suelen estar centrados en la imagen.
- Control de calidad: los formatos más ricos facilitan conservar atributos, indicadores de oclusión, casos difíciles y procedencia de las anotaciones.
- Riesgo de conversión: una conversión simple de COCO a YOLO puede introducir errores si se gestionan mal los ID de categoría, las dimensiones de imagen o la normalización de coordenadas.
En experimentos pequeños, los errores de conversión son molestos. En sistemas de IA en producción, pueden crear ruido de etiquetas oculto que afecta directamente al rendimiento del modelo.
De un vistazo: comparación de formatos
FormatoTipo de archivo típicoMejor paraRepresentación de cajas delimitadorasLimitación principalCOCOJSONDetección, segmentación, puntos clave, conjuntos de datos grandes[x, y, width, height] en píxelesMás complejo de leer, depurar y convertir manualmenteYOLOTXT + YAMLEntrenamiento y despliegue rápidos de detección de objetosclass x_center y_center width height, normalizado de 0 a 1Menos metadatos por defecto; las variantes específicas por tarea difierenPascal VOCXMLDetección de objetos heredada y flujos de trabajo auditablesxmin, ymin, xmax, ymax en píxelesVerboso y menos conveniente para conjuntos de datos modernos a gran escala
En conjuntos de datos centrados en detección, esta decisión está estrechamente relacionada con la forma en que se producen, revisan y exportan las cajas delimitadoras. Si el proyecto se basa principalmente en cajas, consulte nuestra guía sobre servicios de anotación con cajas delimitadoras antes de elegir entre YOLO, COCO y Pascal VOC.
Formato COCO: JSON enriquecido para conjuntos de datos complejos de visión artificial
COCO, abreviatura de Common Objects in Context, es un formato de anotación basado en JSON ampliamente usado para detección de objetos, segmentación de instancias y detección de puntos clave. En lugar de almacenar un archivo de anotación por imagen, COCO suele guardar la información a nivel de conjunto de datos en un único archivo JSON estructurado. Una estructura típica de manifiesto COCO incluye registros de imágenes, registros de anotaciones y definiciones de categorías.
Un archivo COCO simplificado contiene tres secciones principales:
images: ID de imagen, nombres de archivo, anchuras y alturas.annotations: cajas delimitadoras, datos de segmentación, ID de categoría e ID de imagen.categories: ID de clase y nombres de clase.
{
"images": [
{
"id": 1,
"file_name": "image_001.jpg",
"width": 1280,
"height": 720
}
],
"annotations": [
{
"id": 10,
"image_id": 1,
"category_id": 3,
"bbox": [120, 80, 340, 220],
"area": 74800,
"iscrowd": 0
}
],
"categories": [
{ "id": 3, "name": "car" }
]
}
En detección de objetos con COCO, la caja delimitadora suele representarse como [x, y, width, height], donde x e y son la esquina superior izquierda de la caja en coordenadas de píxeles.
Cuándo COCO es una buena elección
- Se necesitan cajas delimitadoras, polígonos, máscaras o puntos clave dentro del mismo ecosistema.
- Se prefiere un único archivo de anotaciones a nivel de conjunto de datos en lugar de miles de pequeños archivos XML o TXT.
- Puede que se entrenen varios modelos a partir del mismo conjunto de datos maestro.
- Se necesita conservar metadatos de anotación más ricos durante el control de calidad, la revisión y la iteración del modelo.
- Se trabaja con frameworks o bibliotecas que ya admiten conjuntos de datos de estilo COCO.
Si la decisión está entre detección solo con cajas y etiquetado basado en máscaras, el formato debe seguir a la definición de la tarea. Para una explicación más detallada, consulte nuestra comparación entre segmentación de imágenes y detección de objetos.
Limitaciones de COCO
- Es más verboso que YOLO y más difícil de inspeccionar manualmente.
- Pequeños errores en JSON pueden romper scripts de entrenamiento o conversión.
- Los ID de categoría deben gestionarse con cuidado, especialmente al convertirlos a índices de clase de YOLO.
- Los archivos COCO grandes pueden ser difíciles de revisar en control de versiones sin herramientas dedicadas.
Recomendación práctica: use COCO como formato maestro cuando se prevea que el conjunto de datos evolucione, cuando quizá se necesiten segmentación o puntos clave más adelante, o cuando varios equipos reutilicen las mismas anotaciones para distintos modelos.
Formato de anotación YOLO: etiquetas ligeras para detección rápida de objetos
El formato de anotación YOLO está diseñado para la simplicidad y la velocidad. En el formato clásico de conjunto de datos de detección YOLO, cada imagen tiene un archivo .txt correspondiente. Cada línea de ese archivo representa un objeto.
La estructura estándar de una línea de detección es:
class_id x_center y_center width height
Ejemplo:
0 0.512 0.438 0.214 0.392
En este ejemplo, 0 es el índice de clase. Los valores restantes son coordenadas normalizadas entre 0 y 1. No son valores en píxeles.
Para una caja delimitadora en píxeles, la conversión al formato de detección YOLO es:
x_center = (x_min + x_max) / 2 / image_widthy_center = (y_min + y_max) / 2 / image_heightwidth = (x_max - x_min) / image_widthheight = (y_max - y_min) / image_height
La mayoría de los conjuntos de datos YOLO también incluyen un archivo de configuración YAML que define las rutas del conjunto de datos y los nombres de clase.
path: /datasets/custom-dataset
train: images/train
val: images/val
names:
0: car
1: pedestrian
2: cyclist
Cuándo YOLO es una buena elección
- Se está entrenando YOLOv5, YOLOv8, YOLO11 u otro detector de la familia YOLO.
- La tarea es principalmente detección de objetos con cajas delimitadoras.
- Se busca una estructura de conjunto de datos compacta, fácil de analizar y rápida de cargar.
- Se prepara un modelo de IA en el borde o de detección en tiempo real donde importan la velocidad de entrenamiento e inferencia.
- El equipo está cómodo gestionando un archivo de etiquetas por imagen.
Limitaciones y matices de YOLO
Las etiquetas clásicas de detección YOLO se centran en cajas delimitadoras. Las variantes modernas de Ultralytics YOLO también admiten tareas como segmentación, estimación de pose y cajas delimitadoras orientadas, pero usan estructuras de etiquetas específicas por tarea. Esta distinción es importante: “formato YOLO” ya no siempre significa un único formato universal.
YOLO es menos expresivo que COCO para proyectos con muchos metadatos. Normalmente no es el mejor formato maestro si se necesitan atributos complejos, metadatos a nivel de instancia, trazas de auditoría detalladas o conversiones repetidas a varios formatos posteriores.
Recomendación práctica: use YOLO cuando la canalización de entrenamiento objetivo ya esté basada en YOLO y la tarea de anotación sea principalmente detección de objetos. Si el conjunto de datos puede requerir más adelante máscaras, puntos clave, atributos o reutilización en varios frameworks, conserve también una exportación maestra más rica.
Formato Pascal VOC: XML para flujos heredados y auditables
El formato XML Pascal VOC es uno de los estándares más antiguos de anotación en visión artificial. Está basado en XML y normalmente almacena un archivo de anotación por imagen. Aunque hoy es menos popular que COCO o YOLO, sigue siendo útil en flujos de trabajo que dependen de herramientas antiguas, modelos heredados o exportaciones XML legibles por humanos.
Una anotación de objeto Pascal VOC simplificada tiene este aspecto:
<object>
<name>car</name>
<pose>Unspecified</pose>
<truncated>0</truncated>
<difficult>0</difficult>
<bndbox>
<xmin>120</xmin>
<ymin>80</ymin>
<xmax>460</xmax>
<ymax>300</ymax>
</bndbox>
</object>
Las cajas delimitadoras de Pascal VOC usan coordenadas en píxeles con xmin, ymin, xmax e ymax.
Cuándo Pascal VOC es una buena elección
- El modelo o script de entrenamiento espera explícitamente XML Pascal VOC.
- Se trabaja con una canalización antigua de detección de objetos.
- Se necesitan archivos relativamente fáciles de inspeccionar manualmente por ingenieros o revisores de control de calidad.
- Se intercambian datos con un cliente o socio cuyas herramientas todavía usan Pascal VOC.
Limitaciones de Pascal VOC
- XML es verboso e ineficiente para conjuntos de datos muy grandes.
- Pascal VOC es menos conveniente que COCO para flujos complejos de segmentación y puntos clave.
- Gestionar un archivo XML por imagen puede volverse engorroso a escala.
- Las canalizaciones modernas de entrenamiento a menudo requieren conversión antes de usarlo.
Recomendación práctica: use Pascal VOC cuando la compatibilidad lo exija. Para proyectos nuevos a gran escala, COCO o YOLO suelen ser más prácticos, según el modelo objetivo.
Otros formatos de anotación que conviene conocer
COCO, YOLO y Pascal VOC cubren muchos proyectos de detección de objetos, pero no son las únicas opciones. Algunos conjuntos de datos e industrias requieren esquemas más especializados. Si todavía se está seleccionando la geometría de etiquetado, revise las principales técnicas de anotación de imágenes antes de decidir el formato de exportación.
LabelMe
LabelMe es un formato basado en JSON que suele usarse para anotación con polígonos y flujos personalizados de segmentación. Es útil para proyectos pequeños y entornos de investigación donde importan la inspección visual y el etiquetado flexible con polígonos.
Cityscapes
Cityscapes se asocia habitualmente con conducción autónoma y comprensión de escenas urbanas. Es relevante para tareas de segmentación semántica y de instancias que incluyen carreteras, carriles, vehículos, peatones, aceras e infraestructura de tráfico.
Open Images
Open Images proporciona una estructura de anotación a gran escala con cajas delimitadoras, etiquetas a nivel de imagen, relaciones y datos de segmentación. Puede ser útil al trabajar con taxonomías amplias de objetos y conjuntos de datos públicos de referencia.
KITTI
KITTI es ampliamente conocido en conducción autónoma, especialmente para tareas de detección, seguimiento, visión estéreo y percepción 3D. Es más específico de dominio que COCO, YOLO o Pascal VOC.
Formatos de producción personalizados
Muchos equipos de IA en producción acaban manteniendo un esquema interno de anotación. Esto puede ser útil cuando el modelo necesita atributos específicos del negocio, historial de control de calidad, puntuaciones de confianza del anotador, estado de revisión, versiones de ontología o enlaces a otros sistemas internos de datos.
La clave es evitar que el proyecto quede bloqueado en un formato personalizado que no pueda exportarse de forma fiable a formatos estándar de entrenamiento.
Problemas comunes de conversión
La conversión de formatos parece sencilla hasta que el conjunto de datos contiene miles o millones de objetos. La mayoría de los errores de conversión no son evidentes a primera vista. Aparecen más tarde como peor rendimiento del modelo, métricas de validación inconsistentes o casos límite mal etiquetados. Unas directrices de anotación claras y las buenas prácticas de anotación de imágenes reducen estos problemas antes de la exportación.
1. Mezclar sistemas de coordenadas
COCO, YOLO y Pascal VOC usan convenciones distintas para las cajas delimitadoras:
- COCO:
[x, y, width, height]en píxeles. - YOLO:
x_center y_center width heightnormalizados. - Pascal VOC:
xmin ymin xmax ymaxen píxeles.
Una conversión correcta debe tener en cuenta la anchura de la imagen, la altura de la imagen y la posición del centro de la caja. Un error común es exportar etiquetas YOLO usando valores en píxeles en lugar de valores normalizados.
2. Perder datos de segmentación o puntos clave
Convertir datos de segmentación COCO a un formato de detección YOLO basado solo en cajas delimitadoras hará que se pierda el detalle de polígonos o máscaras. Puede ser aceptable para un detector de objetos, pero no lo es si el proyecto depende de segmentación de instancias, contornos médicos, siluetas de producto o límites de objeto de grano fino.
3. Mapeo incorrecto de clases
Los ID de categoría de COCO no siempre empiezan en 0 y pueden contener huecos. Los índices de clase de YOLO suelen ser continuos y empezar en cero. Un script de conversión debe crear un mapeo limpio entre los ID de categoría y los índices de clase del modelo.
4. Ignorar las dimensiones de imagen
La conversión a YOLO requiere la anchura y altura correctas de cada imagen. Si los metadatos de imagen faltan o son incorrectos, las coordenadas normalizadas serán erróneas aunque las anotaciones originales fueran correctas.
5. Romper las particiones de entrenamiento, validación y prueba
La conversión de anotaciones debe preservar las particiones del conjunto de datos. Mezclar accidentalmente imágenes de entrenamiento y validación puede inflar las métricas de rendimiento y hacer que el modelo parezca mejor de lo que realmente es.
6. Eliminar atributos y metadatos de control de calidad
Atributos como oclusión, truncamiento, dificultad, notas del anotador, estado de revisión o versión de ontología pueden no sobrevivir a la conversión a formatos más simples. Si estos campos importan, conviene mantener un formato maestro de anotación que los conserve.
Compatibilidad de herramientas: CVAT, Label Studio y frameworks de entrenamiento
La mayoría de las plataformas de anotación pueden exportar a varios formatos, pero el soporte varía según el tipo de tarea. Una exportación etiquetada como “YOLO” puede referirse solo a detección de objetos, mientras que una exportación “Ultralytics YOLO” puede admitir variantes adicionales de tarea, como segmentación o pose. Del mismo modo, una exportación COCO puede admitir detección, segmentación o puntos clave según la configuración de la plataforma. Al seleccionar herramientas, resulta útil comparar herramientas de anotación de código abierto y de pago frente a los requisitos de exportación de la canalización de entrenamiento.
Antes de iniciar un proyecto de etiquetado, verifique tres aspectos:
- Compatibilidad de importación: ¿puede la plataforma de anotación importar las etiquetas existentes del cliente sin perder información?
- Compatibilidad de exportación: ¿puede exportar exactamente el formato que espera el código de entrenamiento?
- Fiabilidad de ida y vuelta: ¿pueden importarse, revisarse, editarse y exportarse de nuevo las anotaciones sin deriva de geometría o metadatos?
Esto es especialmente importante al usar herramientas como CVAT, Label Studio, Roboflow, Supervisely, plataformas de etiquetado personalizadas o motores de datos internos. Por ejemplo, revise los formatos oficiales de exportación de conjuntos de datos de CVAT y los formatos de exportación de Label Studio antes de asumir que una exportación con un nombre determinado admite todas las geometrías o campos de metadatos. El nombre del formato por sí solo no basta. Importan el tipo de tarea y la variante del esquema.
Cómo elegir el formato adecuado para su proyecto
Una decisión práctica debe empezar por el modelo y el flujo de trabajo posterior, no por la herramienta de anotación.
Elija COCO si...
- Necesita segmentación de instancias, máscaras, polígonos o puntos clave.
- Quiere un conjunto de datos maestro que pueda respaldar múltiples experimentos futuros.
- Necesita metadatos más ricos que los que puede almacenar una etiqueta TXT simple.
- El equipo trabaja con PyTorch, Detectron2, MMDetection o herramientas compatibles con COCO.
Elija YOLO si...
- El modelo objetivo está basado en YOLO.
- Las etiquetas son principalmente cajas delimitadoras.
- Quiere un conjunto de datos de entrenamiento ligero, rápido y sencillo.
- Está construyendo detección en tiempo real para dispositivos en el borde, cámaras, drones, vehículos o sistemas industriales.
Elija Pascal VOC si...
- El cliente, el modelo o una base de código heredada requiere anotaciones XML.
- El caso de uso es detección clásica de objetos, no segmentación compleja.
- Los archivos de anotación legibles por humanos son útiles para control de calidad o revisión de ingeniería.
Use una estrategia de maestro y exportaciones si...
En proyectos de producción, el enfoque más seguro suele ser mantener un formato maestro rico y generar a partir de él exportaciones específicas para entrenamiento. Por ejemplo, se puede conservar COCO o un esquema JSON interno como fuente de verdad y luego exportar etiquetas YOLO para entrenar detectores y XML Pascal VOC para el flujo heredado de un socio.
Esto reduce el riesgo de perder información y facilita cambios futuros de modelo.
Formato recomendado según el caso de uso
- Detección de objetos estándar: YOLO si se entrenan modelos YOLO; COCO si importa la flexibilidad de framework.
- Segmentación de instancias: COCO o un formato específico de segmentación.
- Estimación de pose o puntos clave: puntos clave COCO o un esquema de puntos clave específico del framework.
- Flujo empresarial heredado: Pascal VOC si se requiere XML.
- Conducción autónoma: KITTI, Cityscapes, COCO o un esquema personalizado según las necesidades de 2D, 3D, seguimiento y segmentación.
- Imagen médica: a menudo requiere formatos y cadenas de herramientas especializados, en lugar de exportaciones genéricas de detección de objetos.
- Anotación a gran escala con varios equipos: COCO o un esquema maestro personalizado con exportaciones controladas.
Preguntas frecuentes: formatos de anotación COCO, YOLO y Pascal VOC
¿COCO es JSON o XML?
COCO es un formato de anotación basado en JSON. Normalmente almacena información de imágenes, anotaciones y definiciones de categorías en un archivo JSON estructurado.
¿Pascal VOC es XML?
Sí. Las anotaciones Pascal VOC suelen almacenarse como archivos XML, a menudo con un archivo XML de anotación por imagen.
¿Qué es el formato de anotación YOLO?
Para detección de objetos, YOLO suele usar un archivo TXT por imagen. Cada línea contiene el índice de clase y las coordenadas normalizadas de la caja delimitadora: class_id x_center y_center width height.
¿YOLO puede admitir segmentación?
El formato clásico de detección YOLO está diseñado para cajas delimitadoras. Las implementaciones modernas de YOLO, incluidas variantes de Ultralytics YOLO, pueden admitir segmentación, estimación de pose y cajas delimitadoras orientadas mediante formatos de etiqueta específicos por tarea.
¿Puedo convertir COCO a YOLO?
Sí, pero la conversión debe transformar correctamente las cajas de COCO basadas en píxeles a coordenadas normalizadas de YOLO y remapear los ID de categoría a índices de clase YOLO continuos. La segmentación y los metadatos pueden perderse si se convierte a un formato de detección YOLO solo con cajas delimitadoras.
¿Qué formato es mejor para detección de objetos?
No existe un formato universalmente mejor. YOLO suele ser la mejor opción para entrenamiento basado en YOLO y flujos ligeros de detección. COCO es mejor cuando se necesitan metadatos más ricos, segmentación, puntos clave o flexibilidad de framework. Pascal VOC resulta útil principalmente para flujos heredados basados en XML.
Recomendación final
Para la mayoría de los proyectos modernos de visión artificial, use COCO como formato maestro cuando necesite flexibilidad y valor del conjunto de datos a largo plazo. Use YOLO cuando el modelo objetivo esté claramente basado en YOLO y la tarea sea detección de objetos directa. Use Pascal VOC cuando importe la compatibilidad con un flujo XML existente.
Sea cual sea el formato elegido, defina la ontología, las reglas de coordenadas, el esquema de exportación y el proceso de control de calidad antes de que empiece la anotación. Esto evita trabajo de conversión innecesario y protege el rendimiento del modelo más adelante en el proyecto.
¿Necesita ayuda para preparar anotaciones listas para entrenamiento?
DataVLab ayuda a equipos de IA a crear conjuntos de datos limpios, consistentes y listos para modelos en detección de objetos, segmentación, clasificación y flujos personalizados de visión artificial. Nuestros servicios de anotación para visión artificial pueden entregar anotaciones en COCO, YOLO, Pascal VOC o formatos personalizados, con procesos de control de calidad adaptados al modelo y a las restricciones de despliegue.
Contacte con nosotros para revisar sus requisitos de formato de anotación, estructura del conjunto de datos o conversión.




