| Respuesta: Reconstruir imagen
En efecto, tienes razon, eso si que ocurre, es decir, la probabilidad de reemplazar un pixel ya reemplazado segun se avanza en el recorrido de la imagen va en aumento, no sabria calcular una expresion matematica para calcular esta probabilidad, pero no hay que pensar mucho para darse cuenta de que esto sucede.
Una posible forma de solucionar el problema original que planteaba tal vez sea evitar que esto suceda, aunque tambien, por otro lado, no creo que el problema en la reconstruccion de la imagen parta de esta premisa, pondre un ejemplo para explicarme mejor:
-Supongase que la imagen que tengo es de 200x200 pixeles, y que yo voy a reordenar solo 3 pixeles. Las permutaciones que hago serian:
* pixel[0,0] -> lo cambio a posicion [100,100],
* pixel[100,100] -> lo cambio a posicion [0,0]
(ambos quedan permutados), asi que en el fichero escribo lo siguiente 0 0 100 100
Ahora vuelvo a cambiar el pixel [100,100], es decir, cambio un pixel ya cambiado de la siguiente manera:
* pixel[100,100] -> lo cambio a posicion [200,200],
* pixel[200,200] -> lo cambio a posicion [100,100]
(ambos quedan permutados), asi que en el fichero escribo lo siguiente 100 100 200 200
Hasta aqui, si analizamos la imagen:
- el pixel que originalmente estaba en la posicion [0,0] pasa a estar en la posicion [200,200]
- el pixel que originalmente estaba en la posicion [100,100] pasa a estar en la posicion [0,0]
- y el pixel que originalmente estaba en la posicion [200,200] pasa a estar en la posicion [100,100]
Y el fichero finalmente tiene las siguientes entradas:
0 0 100 100
100 100 200 200
Si yo ahora recorro a la inversa en fichero, la primera entrada que obtengo seria:
100 100 200 200
Asi que realizo ese cambio, el pixel de la posicion 200 200 lo cambio por el de la posicion 100 100 y viceversa, el de la posicion 100 100 lo pongo en 200 200
Ahora tengo que:
- el pixel que estaba originalmente en la posicion [0,0]; que es el que acabo en la posicion 200 200, pasa a estar en la posicion [100,100] y en la posicion [200,200] se coloca el pixel que va en su lugar, el 200 200 que habia acabo en la posicion [100,100] en la ultima permutacion
asi que ahora tengo:
posicion original [0,0] -> pixel que contiene [100,100]
posicion original [100,100] -> pixel que contiene [0,0]
posicion original [200,200] -> pixel que contiene [200,200]
Por lo que el ultimo pixel cambiado esta en su lugar, todo correcto
Prosigo, la siguiente entrada que leo del fichero seria
0 0 100 100
vuelvo a realizar el cambio. Resumiendo, una vez realizado el cambio me queda:
posicion original [0,0] -> pixel que contiene [0,0]
posicion original [100,100] -> pixel que contiene [100,100]
posicion original [200,200] -> pixel que contiene [200,200]
Asi que como podemos ver con esta mini-traza, a pesar de que un pixel cambie varias veces su posicion, a la hora de reconstruir la imagen, lo hace bien.
Nose si a la hora de hacer un cambio en todos los pixeles, surge algun error que no me percato, pero la logica me dice que este cambio multiple puede ser resuelto. Hacer una traza para una imagen de 200x200 pixeles seria una locura seguirla, por eso las trazas que he hecho por ahora para analizar su comportamiento son breves
Creo que el problema debe de estar localizado en otro lugar, aunque intentare modificar el algoritmo para que no se permute un pixel ya cambiado haber si esto lo resuelve.
P.D.: Siento la parrafada que he soltado, pero me gusta ser lo mas minucioso posible, mas que nada para que puedan enterderme. Espero haberme explicado bien. Un saludo. |