EAN-13: iluminación y zonas mudas

Objetivo y límites de uso

Conserve símbolo, zonas mudas y coordenadas al comparar luz o estrechar ROI.

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

Prepare barras en material real con reflejos de película y bordes dañados; delimite tinta sin depender de la lectura. Repita la condición después de restaurar la fijación para comprobar reproducibilidad al cambiar formato. Registre luz ambiental y tiempo desde encendido si influyen. No compare máscaras o conversiones de profundidad diferentes como si solo cambiara la luz. Guarde condición descartada, imagen y motivo. Una imagen atractiva no es necesariamente óptima: debe conservar el rasgo y su separación de la variación admisible en todo el rango. 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. Construya una comparación óptica controlada antes de cambiar el umbral. Marque fijación, distancia, ángulo de luz y enfoque para restaurar cada condición. Cambie solo la variable de iluminación o región elegida, manteniendo cámara e identidad de muestra. Conserve el fotograma completo junto a cada recorte o máscara y su transformación a coordenadas originales. Capture variación admisible y un defecto conocido, incluidos los extremos de posición. Compruebe la superposición de la región sobre el original antes de interpretar valores. Reducir una región puede ocultar un fallo; toda zona excluida necesita una razón técnica explícita.

Procedimiento

1. Compare difusa/direccional con exposición fija; revise saturación blanca y barras oscuras.
2. Mapee tinta al original y conserve espacio libre, no solo barras.
3. Pruebe giro y desplazamiento; el rectángulo debe contener todo el símbolo transformado.
4. Guarde original, ROI y revisión; no expanda a una etiqueta vecina para resolver no-read.

Interpretar el ensayo

Ejemplo de imagen de 640 px: tinta x = 120 a 380, ROI x = 80 a 420, con 40 px a cada lado. Margen de diseño, no prueba GS1; las zonas exigidas dependen del tamaño del símbolo.

Hoja de registro

left = 120 - 80 = 40 px
right = 420 - 380 = 40 px

Dos vistas de ingeniería

Diagnóstico de fallos

• Leer con reflejos no demuestra contraste ni calidad de impresión.
• Un código vecino tras ampliar ROI pertenece a otro objeto y no debe sustituir al objetivo.

Aceptación y entrega

Acepte símbolo completo y espacios necesarios vinculados al original en poses admitidas; verifique impresión por separado.

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.