EAN-13: decodificación y reglas de datos

Objetivo y límites de uso

Separe lectura, dígito de control y asociación al catálogo para no aceptar un producto equivocado con un código legible.

Este tutorial describe una evaluación de ingeniería, no una certificación de producto listo para funcionar. El ejemplo público actual de PC de Deyi Vision cubre un flujo EAN-13 con imágenes de muestra confirmadas. Antes de utilizar OCR o detección nativos del código de ingeniería, compruebe el entorno instalado, los modelos vinculados y el trabajo. Una plantilla de navegador no demuestra ejecución en él: el backend OpenCV.js previsto requiere verificación independiente. El reconocimiento en la nube exige aprobar expresamente las imágenes, el proveedor, el modelo y el coste. Un archivo de revisión no es un paquete ejecutable de publicación. Verifique por separado la compatibilidad de cámara, firmware y controlador. Todos los valores de la hoja son hipotéticos; no son mediciones ni resultados de clientes de Deyi Vision.

Preparar las pruebas

Congele simbología, revisión aprobada y no-read; mantenga esperado fuera del decoder y vincule modelos aparte. Compruebe el contrato intermedio antes de leer la bandera final. Región ausente, texto mal formado, coordenada inválida o valor no finito es un fallo explícito, nunca aprobación predeterminada. Registre backend y dependencias reales; no transfiera aceptación entre motores por compartir plantilla. Tras cambiar modelo o preprocesamiento, guarde la versión anterior y repita la comparación fija. Informe todos los intentos, pruebas utilizables y tratamiento del resto: describe cobertura y fallos además de reconocimiento. Separe los registros de decodificación, validación de identidad, verificación de impresión y seguimiento unitario. EAN-13 identifica un artículo comercial y normalmente se comparte entre unidades físicas; no es un número de fotograma ni un serial único. Decodificar no demuestra conformidad de impresión, datos maestros correctos ni rechazo posterior realizado. La serie limita el ejemplo a EAN-13, alcance confirmado de la evaluación pública de PC. Otras simbologías, QR, marcado directo y lectores físicos necesitan integración confirmada por separado. El original debe conservar barras, espacios y zonas silenciosas; un recorte o binario limpio no basta como prueba de fallo. Distinga fotograma ausente y código ilegible en la base de trazabilidad. Trate el flujo como una secuencia de decisiones tipadas, no como una sola respuesta del modelo. Vincule identidad de entrada, transformación de región, versiones de nodos, preprocesamiento y paquete de modelo antes del ensayo. Separe la elección de parámetros con imágenes de desarrollo de la evaluación de un conjunto congelado cuyas respuestas no se hayan usado para ajustar. Conserve resultados de referencia y candidato para todos los casos, incluidos errores. La IA puede proponer una revisión, pero no confirmar respuestas, autorizar transferencias ni aprobar producción. Si la recepción del proveedor es incierta, conserve la identidad de solicitud e investigue el comprobante antes de considerar un reenvío. Disponibilidad, calidad y aprobación son verificaciones independientes.

Procedimiento

1. Lea ROI original y guarde payload, simbología e ID antes de validar.
2. Revise longitud y control sin reparar con la respuesta esperada.
3. Busque catálogo aprobado y distinga identificador desconocido de producto discrepante.
4. Estructure lectura, no-read, dato inválido, discrepancia y error; pruebe antes de PLC.

Interpretar el ensayo

Con 123456789012 hipotético, sumas alternas 26 y 22: 26 + 3 × 22 = 92, dígito 8, código 1234567890128. Ejercicio aritmético, no GTIN asignado a un cliente. Control correcto no confirma producto esperado.

Hoja de registro

W = 26 + 3 * 22 = 92
c = (10 - (92 % 10)) % 10 = 8

Dos vistas de ingeniería

Diagnóstico de fallos

• Reparar checksum puede convertir etiqueta errónea en falso acierto.
• Una respuesta sin simbología o ID es incompleta aunque parezca plausible.

Aceptación y entrega

Acepte reglas con imágenes independientes y catálogo aprobado. Mantenga lectura, control y asociación separados; ninguno solo verifica impresión GS1.

Conserve juntos imágenes originales, decisión esperada, revisión exacta y registro completo. Congele el conjunto de evaluación antes de elegir los parámetros finales. Si después utiliza sus respuestas para ajustar el flujo, márquelo como datos de desarrollo y obtenga otro conjunto independiente de aceptación. Mantenga Review, NoResult, error de ejecución y adquisición ausente en el denominador; no los convierta en aprobaciones filtrando filas. Guarde un fallo reproducible junto al caso satisfactorio. La entrega debe identificar quién puede cambiar la receta, cómo restaurar una revisión aprobada y qué salida del equipo seguirá bloqueada hasta la aceptación. Un resultado de software no demuestra que una pieza en movimiento haya llegado al destino correcto.