Etiquetas OCR: ilegible o texto incorrecto

Objetivo y límites de uso

Localice fallo en píxeles, geometría, reconocimiento o regla sin modificar la respuesta esperada.

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

Guarde por separado caso estrecho y campo normal; mantenga lote esperado. Escriba un registro reproducible con fuente, región, salida real, decisión esperada y primera divergencia. Indique si ocurre en reproducción, captura real o ambas. Tras corregir, repita el fallo y condiciones vecinas antes satisfactorias. Excluir la región o aceptar un resultado ausente cambia el requisito, no resuelve la causa. Si persiste, mantenga Review o bloqueo con motivo, sin presentar una alternativa no probada como validada. 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. Diagnostique desde la primera divergencia observable. Reproduzca la misma fuente guardada con referencia y candidato sin cambios; compare imágenes intermedias, regiones, valores y estados. Si cambia la fuente, ya no se aísla el algoritmo. Modifique una sola causa sospechosa, anote antes el efecto esperado y conserve el resultado negativo cuando falle la hipótesis. Separe evidencia ilegible, desacuerdo de regla, dependencias ausentes y fallo de ejecución: requieren remedios distintos. La reproducción puede demostrar un fallo de software, pero no validar disparo real, sincronización de luz ni rechazo físico. Mantenga esas pruebas de adquisición y línea como experimentos posteriores independientes.

Procedimiento

1. Reproduzca original y registre NoResult/Review sin rellenar respuesta.
2. Compare altura, márgenes y polígono; separe rechazo de entrada y discrepancia reconocida.
3. Examine texto bruto; no amplíe alfabeto para forzar éxito.
4. Recapture tras corregir y conserve entrada nueva, sin reparar retrospectivamente el ensayo original.

Interpretar el ensayo

El límite documentado usa 160 × 8 y LOT123; NoResult/Review es resultado honesto. La referencia 160 × 64 no garantiza cualquier campo mayor. Rellenar o estirar modifica el ensayo y no borra el fallo.

Hoja de registro

Dos vistas de ingeniería

Diagnóstico de fallos

• Dar la respuesta al modelo invalida el experimento.
• Si el polígono corta un trazo, arregle captura/mapa antes del diccionario.

Aceptación y entrega

Cierre tras identificar la primera etapa fallida y evaluar una captura independiente. Mantenga resultado original y denominador completo.

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.