Clasificación SKU: reglas de color y producto

Objetivo y límites de uso

Decida color con formato declarado y separe SKU semántico y aprobación cloud.

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

Congele canales, profundidad, máscara y clases; vincule ejecución local, pues plantilla/archivo no aporta runtime. Compruebe el contrato intermedio antes de leer la bandera final. Región ausente, texto mal formado, coordenada inválida o valor no finito es un fallo explícito, nunca aprobación predeterminada. Registre backend y dependencias reales; no transfiera aceptación entre motores por compartir plantilla. Tras cambiar modelo o preprocesamiento, guarde la versión anterior y repita la comparación fija. Informe todos los intentos, pruebas utilizables y tratamiento del resto: describe cobertura y fallos además de reconocimiento. 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. Trate el flujo como una secuencia de decisiones tipadas, no como una sola respuesta del modelo. Vincule identidad de entrada, transformación de región, versiones de nodos, preprocesamiento y paquete de modelo antes del ensayo. Separe la elección de parámetros con imágenes de desarrollo de la evaluación de un conjunto congelado cuyas respuestas no se hayan usado para ajustar. Conserve resultados de referencia y candidato para todos los casos, incluidos errores. La IA puede proponer una revisión, pero no confirmar respuestas, autorizar transferencias ni aprobar producción. Si la recepción del proveedor es incierta, conserve la identidad de solicitud e investigue el comprobante antes de considerar un reenvío. Disponibilidad, calidad y aprobación son verificaciones independientes.

Procedimiento

1. Convierta con orden correcto y declare HSV antes de rangos.
2. En ensayo OpenCV de 8-bit, rojo cruza H 0–10 o 170–179; elija S/V con muestras, no valor universal.
3. Cuente píxeles válidos, devuelva Review ante evidencia insuficiente y conserve ratio.
4. Evalúe SKU con identidades aprobadas; cloud exige aprobación de datos, proveedor, modelo y coste.

Interpretar el ensayo

Ejemplo: 600 de 1000 píxeles son 60%; criterio de ensayo 70% devuelve Review sin forzar rojo. Valide rangos/ratio en profundidad y productos reales. Color no distingue SKU del mismo color.

Hoja de registro

ratio = 600 / 1000 = 60%
60% < 70% -> Review

Dos vistas de ingeniería

Diagnóstico de fallos

• Rangos de otra profundidad cambian la frontera sin avisar.
• Confianza cloud alta sin catálogo o evidencia del objeto no autoriza ruta física.

Aceptación y entrega

Acepte color con muestras independientes conocidas/desconocidas y luego producto. Vincule rangos, máscara, paquete y modelos al resultado.

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.