Clasificación SKU: canales y deriva

Objetivo y límites de uso

Encuentre primera discrepancia en captura, conversión, máscara o regla antes de forzar umbrales hacia SKU esperado.

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 color original, neutro y objeto nuevo; deje respuesta fuera de entrada y registre revisión. 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. 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. 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. Examine orden de canales y píxel conocido antes de convertir.
2. Reproduzca original con conversión declarada y compare máscara/denominador.
3. Revise deriva blanca, clipping y baja saturación aparte; color no observable queda desconocido/Review.
4. Valide con nuevas capturas y clases próximas, conservando error original.

Interpretar el ensayo

El mismo color hipotético es RGB [200,40,30] o BGR [30,40,200]. Cambiar etiquetas sin respetar entrada cambia significado. Un píxel/preview no prueba SKU. Un original gris no recupera color con otro código de conversión.

Hoja de registro

Dos vistas de ingeniería

Diagnóstico de fallos

• Rojo convertido en azul sugiere canales; compare primero píxel fuente.
• Cambiar clase solo por fondo sugiere máscara/denominador, no nuevo color de producto.

Aceptación y entrega

Cierre al reproducir y corregir primera diferencia y verificar muestras independientes conocidas/nuevas. Mantenga ambigüedad y documente etapa cambiada.

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.