Crear una transformación euclídea para pasar de las coordenadas que se tienen en la imagen fuente a la imagen destino de la región a calcular.

[BlancaCC]

Crear una transformación euclídea para pasar de las coordenadas que se tienen en la imagen fuente a la imagen destino de la región a calcular. Hay que tener cuidado porque esta función afecta a otras como:

• sourceBondary

Probablemente haya que añadir un parámetro que acepte la función inversa de la euclídea definida y vaya cambiando las coordenadas.

[Exequielac]

He estado reflexionando sobre esto, quizás sea mejor implementar una función aparte que dada la matriz, realiza la transformación euclídea de la imagen a copiar a las coordenadas de la imagen target (son operaciones diferentes y así no la lío modificando la función sourceBoundary).

[BlancaCC]

@Exequielac Sí, lo ideal sería tener otra función y componerlas

[Exequielac]

He empezado la implementación y me he quedado un poco estancado. A continuación resumo las ideas que he tenido:

1. Función que dados los parámetros: traslación de píxeles en x, traslación de píxeles en y y un grado de rotación devuelve la matriz que realiza la transformación.
2. Función que dada la región seleccionada, las dos imágenes y la transformación: se calcula el nuevo conjunto de puntos tras la aplicación de la transformación. En esta función se debe de tener en cuenta que al realizar la transformación puede que haya píxeles que se queden "en mitad" de otros píxeles: Mi aproximación inicial es incluirlos todos.
3. Quedaría por ver qué hacer cuando, en el nuevo conjunto de píxeles, se le aplica la transformación inversa y el píxel no cae en un píxel: primera aproximación es realizar interpolación bilineal.

[BlancaCC]

@Exequielac Por este commit entiendo que has empezado la implementación. Cuando lo más sencillo sería comenzar con la parte matemática, que contempla todos los casos y no da lugar equívocos. Una vez se tenga eso, la traducción del código sería directa.

https://www.ugr.es/~fjlopez/_private/Geometria_III.pdf

Aquí diría que está toda la teoría que te hace falta. De todas formas a lo largo de la mañana puedo formalizarlo yo si quieres

[BlancaCC]

@BlancaCC Intentaría enfocarlo de la siguiente manera:

1. Los movimientos que se deben permitir bajos las hipótesis del problema son los movimientos rígidos http://descartes.cnice.mec.es/Descartes1/Geometria/Movimientos_en_el_plano/Ricardo_Alonso_UD.htm

(Simetrías, translaciones y rotaciones y sus composiciones)

Estos tienen asociadas una matriz, te dejo que la busques tú 😜

Otros tipo de transformaciones alteraría las distancias y entonces trataríamos con otro problema al que resolver.

Respecto a la implementación:

• nosotros vamos a escribir directamente la matriz a aplicar

Para un sistema más avanzado bastaría con fijar tres puntos de en la imagen fuente y manteniendo distancias y ángulo colocar esos tres puntos en la imagen destino. Cómo tres puntos definen una transformación solo habría que calcularla (find homography de opencv creo que lo hacía)

[BlancaCC]

He visto que has definido las siguientes tareas pendientes:

1 TODO: función que reciba una matriz de transformación, la región de inicio y la imagen destino, calcule la nueva región después de la transformación 2 TODO: funciones de interpolación lineal y bilineal 3 TODO: modificación de la función GuidanceFieldGenerator para que tenga en cuenta la transformación inversa.

No termino de entender 1 y 2. Sin embargo 3, creo que se puede cambiar un poco la implementación general, haciendo que la región seleccionada que ahora mismo es un conjunto de 2-uplas de coordenada $(x,y)$ a una 3-upla de $(x,y,g_{x,y})$ es decir: coordenadas y su imagen.

[Exequielac]

@BlancaCC 1: Cuando se tiene una transformación y un pixel, por ejemplo, (3,2) y se le aplica la transformación y el resultado es, por ejemplo, (12.5, 17.5). ¿Que hacer en este caso? 2: En el caso de la transformación inversa, si se tiene el pixel (12, 10) y al aplicarle la transformación inversa el píxel cae en (3.5, 4.5), ¿Como calcular el valor de la función en ese punto? Había pensado en usar interpolación.

[BlancaCC]

@Exequielac Mientras comía he estado pensando en el problema y he llegado a las siguientes conclusiones:

• La única operación que da problema de redondeo son los giros. Así que la que hay que trabajar con cuidado es esa transformación.

Expongo posibles soluciones ordenadas de menor coste computacional a más:

Si trabajamos directamente de manera analítica y después usando un redondeo o trucando del valor para asignarlo a los píxeles seguramente se pierdan algunos. Sin embargo la clave puede estar en ¿Cuánto de mala es esa solución? Porque a lo mejor es imperceptible para el ojo humano, todo es probar.

La segunda podría ser aplicar interpolación, pero aumentaría el coste y ¿Habría mucha diferencia con respecto a usar redondeo? (Hay algo de mí que me dice que no renta, pero todo es probarlo).

Tercera opción: está serviría si se quiere tener los pixeles idénticos y la idea es la siguiente:

Pensar en los pixeles seleccionados como un tablero de ajedrez o rejilla. Para un pixel o cuadro concreto existen 8 vecinos. Cuando se aplique el giro estos 8 vecinos deberían de ser los mismos. Luego el algoritmo determinaría las nuevas posiciones de estos.

El problema aquí es:

• limitación de ángulo de giro
• costo computacional.

---

Respecto al issue de la inversa se podría solucionar no teniéndola que calcular :D

( Se modifica directamente la función de vectores guía para que tome directamente los valores en el dominio transformado)

[BlancaCC]

Para cerrar este issue falta:

• Añadir una imagen con los fondos más parecidos para comprobar la teoría de porqué el soso es azul.
• Redactar correctamente todo el proceso.

[BlancaCC]

Ya solo falta:

• limpiar el código (eliminar TODOs) y reorganizar el orden de las casillas según se crea conveniente.
• Añadir numeración de las casillas con Código x : Desccripción de una frase
• Añadir numeración de todas las figuras.
• Comentar el algoritmo seguido, para la translación en color.
• Explicar cómo se razonó en el issue #19 el motivo por el que un oso primero sale azul mientras que el oso polar cambiando fondo tiene un resultado mucho mejor.

Cuando todo esto esté hecho hacer (por favor) un full request a main y que el otro revise y mergee :D