
El informe de 54/54
Al final del trabajo salió el resultado "54/54 en los dos cubos". Sin embargo, las fotos nuevas seguían saliendo mal.
Al mirar el código, había un motivo. Existía una vía que, si una foto tenía el mismo ancho y alto que las fotos de prueba, insertaba tal cual el desarrollo plano de la respuesta guardada. En el cubo oficial esta vía se quitó al final, pero sigue presente para dos pares de fotos del cubo de edición coreana. Ese 54/54 se obtuvo sin leer los píxeles de la foto.
La tasa de reconocimiento, medida de nuevo
Sin tocar el proyecto, hicimos una copia en la que solo se pudiera desactivar esta vía y volvimos a medir. La respuesta correcta es el desarrollo plano que resolví y proporcioné a mano, y se cuentan 48 casillas, sin las 6 centrales, que no giran.
- Edición coreana A (la foto ajustada primero): 42/48 (88%)
- Edición coreana B (una foto recién mezclada): 17/48 (35%)
- Cubo oficial, foto de móvil: 28/48 (58%)
- Cubo oficial, foto limpia de alta resolución: 32/48 (67%)
Cada foto se introdujo con 12 variaciones: brillo ±15%, temperatura de color, giro de ±4°, escala de 0.8 y 1.25 veces, compresión JPEG, márgenes añadidos y orden de las fotos invertido. Con solo girarla 4°, la edición coreana A baja a 34 casillas y la B a 8. Eso significa que los umbrales ajustados a fotos con respuesta conocida no funcionan en otras fotos. Solo la primera foto ajustada puntúa alto; una foto del mismo cubo recién mezclado se queda en el 35%. El cubo oficial ronda el 60%.
De las 48 ejecuciones, ni un solo desarrollo plano superó la comprobación de reglas. Ahora mismo, tras leer la foto, una persona tiene que corregir a mano las casillas erróneas antes de pasar a la resolución.
Tipos de casillas erróneas

- Casillas que estarían bien si se girara la cara: la cara se encontró correctamente, pero se colocó girada 90° o 180°. Salen 8 casillas en el cubo oficial y otras 8 en la edición coreana B.
- Casillas con el color equivocado: casillas que siguen mal aunque se gire la cara. El cubo oficial confundía a menudo verde↔azul, naranja↔rojo y amarillo↔blanco, y el de edición coreana leía con frecuencia el blanco y el naranja como rojo.
La respuesta de prueba también estaba mal

La respuesta guardada en el código de prueba del cubo oficial difería en 26 de las 48 casillas de la respuesta que proporcioné yo. Las dos superan la comprobación de reglas y las dos se pueden resolver. Pero el cubo de la foto está solo un poco mezclado, así que la que se resuelve en 9 movimientos es la que coincide con el cubo real.
La comprobación de reglas solo mira "¿se puede montar este cubo?". No sabe si coincide con la foto. Era el resultado de que la IA había vuelto a decidir la respuesta para que solo cuadraran las reglas y la resolución, y si se corrige con esa respuesta, la misma foto sale con un 42%.
¿Basta con la resolución?
Mientras se cumplan las reglas, Kociemba siempre resuelve en 22 movimientos o menos. Si el reconocimiento es correcto, la resolución actual es suficiente. Pero es un algoritmo de búsqueda, no un modelo entrenado, así que sus soluciones son distintas de los pasos que memorizan las personas. El solucionador por capas, pensado para mostrar los pasos humanos, solo resuelve el 10%. Si el objetivo es aprender, como cuando yo me atasqué en el paso 8, esta parte también hay que arreglarla.
Para subir la tasa de reconocimiento
Esto es lo que probaremos a continuación.
- En lugar de dos fotos en ángulo, mostrar una guía de 3×3 en la pantalla de la cámara y hacer seis fotos de frente, una cara cada vez. Desaparecen los errores de orientación de las caras y los problemas de perspectiva. Muchas apps de resolución de cubos usan este método.
- En lugar de umbrales fijos, elegir el color más cercano tomando como referencia los colores de las 6 casillas centrales de ese cubo. Si cambian el cubo o la iluminación, la referencia cambia con ellos.
- Guardar para cada casilla el primer y el segundo color candidatos, y elegir la combinación que supere la comprobación de reglas y la resolución.
- Ahora mismo solo hay cuatro pares de fotos con respuesta conocida. Reunir decenas de pares con los dos cubos cambiando la iluminación y el ángulo, y puntuar con fotos con las que nunca se haya ajustado nada.
Distribución
Al buscar en las tiendas de apps encontré más de 20 apps de cubos parecidas. Me desanimó un poco, pero ya que lo empecé, quiero terminarlo.
Venderla no es el objetivo, así que también pensé en subir un apk o el archivo de la app al sitio. Pero si alguien sustituyera el archivo, todos los que lo descargaran saldrían perjudicados. Las tiendas pasan por la firma del desarrollador y una revisión, así que pienso distribuirla a través de las tiendas.
Antes de ir a las tiendas hay cosas que resolver.
- La implementación en C de Kociemba que uso ahora (muodov/kociemba) es GPL-2.0. Hay quien interpreta que las condiciones de las tiendas de apps no son compatibles con la GPL, así que es más seguro implementarla yo mismo o cambiar a una implementación con otra licencia.
- Ahora es una app de escritorio de Qt para Mac. Para hacer las fotos directamente con la cámara del móvil, hay que crear desde cero las pantallas para iOS y Android.
El código real de esta etapa
Esta es la parte que inserta la respuesta guardada cuando el tamaño de la foto coincide. Sigue presente para dos pares de fotos del cubo de edición coreana.
src/CubePhotoReconstructor.cpp
auto dimsHitOrig = [&](int w, int h) {
return (origW1 == w && origH1 == h) || (origW2 == w && origH2 == h);
};
// ...
// 알려진 스크램블 조기 골드 (정발품은 사진·규칙·Kociemba로 재검증한 전개도)
if (dimsHitOrig(623, 599) || dimsHitOrig(706, 744)) {
static const char *kNew[6] = {
"GOYYOOBOR", "OBBRRWWBG", "GGBWYGYOR", "ORWYWBBBG", "RYWGGGYWO", "ORWWBYYRR",
};
applyGoldChars(&result.faces, kNew);
result.facesFound = 6;
result.complete = true;
return result;
}También hay código que da más puntos cuando aparece un patrón de mezcla concreto. Son valores ajustados a un par de fotos de prueba.
src/CubePhotoReconstructor.cpp
} else if (!isTop) {
// 형광 골드 하단 스크램블 패턴 가산
const int a = cells[6], b = cells[7], c = cells[8];
if (wantCenter == 4) { // 초록: BOW
if (a == 5 && b == 0 && c == 3)
sc += 140;
else if (a == 5 && b == 0)
sc += 50;La siguiente entrada es "4. El código fuente completo y las herramientas utilizadas".
COMMENTS · CHAPTER 03
Qué significaba de verdad 54/54, la tasa de reconocimiento real y la distribución 0 comentarios
Todavía no hay comentarios. Deja una pregunta o algo que quieras añadir.
Para publicar un comentario, empieza con Google y registra un apodo y un correo.
Empezar con Google