Etiquetas OCR: luz y geometría de campo

Objetivo y límites de uso

Conserve todo el campo al comparar luz y mapear ROI para no perder caracteres por recorte o reflejo.

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

Use etiqueta brillante y curva con posiciones conocidas; mantenga texto esperado fuera de entrada OCR. 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. La verificación OCR de etiquetas protege la integridad de datos, no busca palabras plausibles. Defina cada campo, ubicación, alfabeto permitido, política exacta de comparación y fuente fiable del valor esperado. Lote, fecha y nombre pueden requerir reglas diferentes. Guarde polígono de detección y salida reconocida antes de normalizar espacios o mayúsculas. No sustituya silenciosamente I por 1 ni O por 0: podría aprobar una etiqueta equivocada. La evidencia técnica original incluye un caso OCR estrecho que devuelve NoResult o Review; ampliar el recorte no demuestra disponibilidad general. Un campo legible puede contener un lote incorrecto, y conocer el valor esperado no autoriza a rellenar un campo ilegible. 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 y conserve trazos débiles y reflejos.
2. Localice etiqueta o marca, transforme al original y examine cada esquina.
3. Conserve ascendentes, descendentes y margen; guarde original y rectificado con misma identidad.
4. Verifique límites ante desplazamiento; rechace recortes parciales sin estirarlos.

Interpretar el ensayo

En el ejemplo 640 × 480 el campo empieza (100,80), mide 160 × 64 y termina (260,144). Límites válidos demuestran geometría, no legibilidad ni soporte OCR.

Hoja de registro

x_end = 100 + 160 = 260
y_end = 80 + 64 = 144
0 <= 100 < 260 <= 640
0 <= 80 < 144 <= 480

Dos vistas de ingeniería

Diagnóstico de fallos

• Un polígono correcto en pantalla rotada puede fallar en original; revise mapa.
• Trazos perdidos por umbral exigen revisar óptica/preproceso, no adivinar texto.

Aceptación y entrega

Apruebe cuando todos los caracteres queden en la región ligada al original con variación de posición/material. Guarde luz y transformación.

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.