Clasificación SKU: luz y máscara del objeto

Objetivo y límites de uso

Compare color en región estable sin que sombras, brillos o fondo redefinan la muestra.

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 neutro y formas reales con luz difusa; defina superficie representativa antes de ver clases. 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. Clasificar por color y reconocer SKU responde preguntas distintas. Una región puede coincidir con el rojo de referencia y pertenecer al tamaño, etiqueta o envase equivocados. Defina si se clasifica el color físico, se verifica el SKU esperado o se exigen ambos controles independientes. Use imágenes de color con orden de canales conocido y guarde exposición, balance de blancos y espectro de luz en la receta. Pruebe lotes admisibles, brillo, sombras y productos ajenos, no solo una carta limpia. Con baja saturación el tono es poco fiable; los reflejos saturados pierden información irrecuperable. Defina una ruta para artículos desconocidos, no observables y multicolor. Valide el modelo de SKU aparte del umbral cromático y apruebe previamente toda transferencia a la nube. 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 luz con cámara fija y revise desequilibrio/clipping en neutro.
2. Localice objeto y mapee máscara al original, quitando fondo conocido sin cortar material de clase.
3. Registre píxeles válidos y exclusiones; no quite un parche difícil solo porque clasifica mal.
4. Guarde máscaras base/candidata de mismos objetos y varíe pose/acabado antes de congelar ROI.

Interpretar el ensayo

Ejemplo: ventana 2000 píxeles, objeto válido 1000. Un conteo 600 usa denominador del objeto: 60%, no 30% de ventana. La máscara cambia el significado; conserve exclusiones y motivos auditables.

Hoja de registro

object_ratio = 600 / 1000 = 60%
window_ratio = 600 / 2000 = 30%

Dos vistas de ingeniería

Diagnóstico de fallos

• Un conveyor coloreado puede dominar ROI.
• Excluir casi toda superficie por brillo requiere evidencia insuficiente, no clase forzada.

Aceptación y entrega

Acepte luz/geometría con material observable y denominador estable; umbrales y SKU siguen después.

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.