Showing posts with label retos lúdicos. Show all posts
Showing posts with label retos lúdicos. Show all posts

Sunday, July 22, 2018

Un nuevo reto lúdico: los números de Munchhausen




Las matemáticas recreativas siempre presentan posibles retos para la programación. En esta ocasión hablaremos de los curiosos números de Munchhausen y plantearemos el reto a solucionar.

Dice la Wikipedia: "un número de Munchhausen (o Münchhausen) es un número natural n el cual la suma de sus dígitos (en base 10), elevados a la misma potencia de ellos mismos es el mismo número es decir n. Por ejemplo:

3435 = 3^3 + 4^4 + 3^3 + 5^5 = 27 + 256 + 27 + 3125 = 3435.

El término fue una invención del ingeniero y matemático holandés, Daan van Berkel, que en el 2009 estudió este tipo de números. La idea de llamarlos así a estos números se debe a que cada dígito está "elevado" por sí mismo y esto evoca la historia de Barón Munchhausen que se elevó a sí mismo hacia arriba jalando su propia coleta. Como todos sabemos, el Barón de Munchhausen era un mentiroso crónico e inventaba las más increíbles historias, recopiladas en un libro incluso.

La idea de estos números puede dar a un nuevo reto lúdico. Se trata de averiguar cuántos números hay con esta propiedad. El 1, por ejemplo, cumple pues es 1^1 = 1. El segundo número es el 3435 y parece que no hay más. Consideramos normalmente que 0^0 = 1, pero si tomamos la definición "no estándar" de que 0^0 = 0, entonces el número 438,579,088 es también de Munchhausen.

El reto lúdico es pues escribir un programa que dado un intervalo de números naturales, empezando en 1 y terminando en el número que se deseé, el programa encuentre en el menor tiempo posible cuáles son los números de Munchhausen. Aunque ya sabemos la respuesta, el ganador del reto será quien encuentre en el menor tiempo posible el resultado correcto, considerando un intervalo de al menos 10 millones de números: del 1 al 10 millones. Además, el programa deberá usar la definición estándar de 0^0 = 1 y 0^0 = 0, esto, desde luego, por separado.

Cabe señalar que yo ya escribí mi propia versión del reto. En este caso, le puse una opción que me dice qué número está procesando, pero para efectos de mediciones, le puedo quitar eso porque el despliegue de esta información hace mucho más lenta la ejecución del software.


El reto tendrá como premio una taza de la Morsa. Si el ganador es de provincia, se le mandará un USB de 8 GB al menos, porque mandar una taza por mensajería es ridículamente costoso. Cabe señalar que este concurso busca simplemente alentar el trabajo de la programación y mostrar que puede ser lúdica. Es un concurso de buena fe. Si hay, por ejemplo, dos o más respuestas satisfactorias, ganará quien la haya mandado primero. El ganador cede su código fuente a la comunidad. Es decir, se promueve el código abierto.

Las respuestas al reto deben mandarlas a morsa@la-morsa.com. A quien le interese ver mi programa corriendo, envíeme un mensaje a mi correo y le mandaré el enlace para que lo descarguen y vean mis resultados. ¡Suerte!

Wednesday, September 13, 2017

Reto lúdico: Números palindrómicos, el problema del número 196


Un nuevo reto de la programación lúdica: Sabemos que el número 196 no se ha podido demostrar que es palindrómico. Hállese la mayor cantidad de iteraciones y el mayor número al que se pueda llegar sin que el programa falle. Ése es el reto.

Aún en esta era de la computación masiva, no se ha hallado que la conjetura sobre los números capicúas, que fue el reto de programación lúdica pasado, funcione para el número 196, la cual sigue siendo un problema matemático sin resolver. Se sabe que los números, entre el 100 a 999, 13 no llevan a ningún palíndromo. Estos son: 196, 295, 394, 493, 592, 689, 691, 788, 790, 879, 887, 978, 986. El 196 es el primero de ellos y evidentemente su retrógrado el 691 tampoco llega a ser capicúa.

Podemos entonces considerar dos grupos, el primero, conteniendo 196, 295, 394, 493, 592, 689, 691, 788, 790, 887 y el 986, y un segundo grupo compuesto por el 879 y el 978. A los números 196 y 879 se les llama “números generadores” o “semillas”. La razón de esto es que el 691 es el retrógrado del 196 por lo que son parte del mismo grupo: 196 + 691 = 691 + 196 = 887. El número 295 y el 592 llevan al mismo número, 887, después de una primera iteración, por lo que se consideran parte del mismo grupo.

En abril de 1984 apareció en la columna de Scientific American “Computer Recreations”, un artículo sobre estos patrones matemáticos   y los esfuerzos para probar la conjetura han sido extraordinarios. Por ejemplo, John Walker indica que el 12 de agosto de 1987 puso su estación de trabajo Sun 3/260 para tratar de resolver si el 196 era un número palindrómico. El programa tenía algunos controles, que se guardaban en un archivo cada dos horas y en caso necesario el sistema reiniciaba la tarea desde los últimos datos hallados en dicho archivo. Así, si algo fallaba (por ejemplo, se cortaba la energía eléctrica), podía reanudarse el proceso sin problemas. Entonces el programa corría día y noche sin intervención humana.

Dice Walker que finalmente, casi cuando se cumplían tres años de ejecución ininterrumpida del software, cinco minutos antes de la media noche, el programa mandó el siguiente mensaje:

Stop point reached on pass 2415836.
Number contains 1000000 digits.

(El número contiene 1000000 de dígitos)
(Punto de detención en la iteración 2415836)

Así entonces, el número 196 había crecido hasta un millón de cifras sin que fuese palindrómico.

Esto podría quizás considerarse el final de la historia, pero sorpresivamente en 1995, Tim Irvin retomó el trabajo de Walker usando una supercomputadora, empezando en el número de un millón de cifras y cuando el sistema llegó a un número con dos millones de cifras, encontró también que no había sido localizado ningún número palindrómico.

Irvin inició su búsqueda el 5 de julio de 1995 y después de una semana de pruebas y corrección de errores, el programa trabajó casi ininterrumpidamente, a excepción de las horas de respaldo diario del sistema. En la mañana del 22 de agosto de ese mismo año, el programa se detuvo en los dos millones de cifras, de nuevo, sin encontrar el ansiado número capicúa.

Irvin terminó su búsqueda y aunque ha jugado con la idea de seguirla, considerando que el sistema de súper cómputo se ha renovado, parece decidido a no continuar por diversas razones. Por una parte, el tiempo de súper cómputo no es barato y por otra parte, hay muchos problemas más importantes que atacar que el resolver la conjetura. No obstante esto, Irvin pone a la disposición el programa y los controles para que el sistema se detenga cuando se llegue a 3 millones de cifras.

Pero Jason Doucette, en 1999 decidió retomar el trabajo de Irvin y usando una computadora casera, entró a esta gran búsqueda. En este caso, el programador desarrolló software en ensamblador (buscando optimizar los recursos), y en 1999, el 9 de agosto, se inicio la ejecución del software, en una máquina Pentium II, a 266 Mhz. El sistema alcanzó la marca de un millón de cifras en 1 día y 18 horas, lo cual es notable si consideramos que Walker tardó 3 años casi en llegar a esa cantidad de cifras.  5 días y 10 horas después, Doucette llegó a la marca de los 2 millones de cifras. Se compararon los resultados y no se hallaron divergencias, por lo que se asume que el software no tiene errores.

La marca de los tres millones de cifras se alcanzó 8 días y 7 horas después. Desde luego, mientras mayor es el número más sumas tendrá que hacer. 13 días y 8 horas después se alcanzó la cifra de 5 millones de dígitos. Al llegar a este resultado, Doucette cambio de hardware y el programa reinició su búsqueda en una máquina Celeron, con un procesador de 400 Mhz (lejos, muy lejos, del estándar actual).

Eventualmente Doucette llegó a más de 13 millones de cifras y ahí decidió detenerse aparentemente  . Sin embargo, Ian Peter logró la cifra de 10 millones de dígitos en poco más de cinco horas. Esto lo hizo en una máquina de 500 Mhz Athlon.

El trabajo de Ian Peter es además interesante porque encontró algunos números palindrómicos que tardan más que las 24 iteraciones que la mayoría de los números necesita. En la siguiente tabla se observan estos números palindrómicos, con sus respectivas iteraciones y el palíndroma generado:

Finalmente Wade van Landingham entró a la búsqueda y a partir de casi 14 millones de cifras de Doucette, llegó a un número de 300 millones de dígitos, lo cual son casi 725 millones de iteraciones y de nuevo, parece no encontrarse el capicúa que se inicia con 196. Sin embargo, hay que hacer énfasis en que hasta el momento lo único que podemos concluir es que no se sabe si el 196 es número palindrómico. Esto sigue siendo indecidible  .
El hecho de que no todos los números sean capicúas podría hacernos pensar que existe una asimetría en la conjetura, aunque en términos reales, no es el único número que no cumple con ello. Los matemáticos se preguntan, sin embargo, ¿Qué tiene de especial el número 196?

Todo lo anterior es simplemente el preludio del nuevo reto de programación lúdica. Se trata de procesar el número 196 para ver si es palindrómico (lo cual no sabemos a pesar de que se han hecho millones de iteraciones) y entregar el número más grande al que el programa del concursante pueda llegar. Por ejemplo, si pusiésemos a trabajar el 89 y llegásemos a la iteración 24 que da 8813200023188, éste sería el valor más grande que podríamos encontrar del número con el que partimos. Pero en el caso del 196 no parece haber un límite de iteraciones y de lo que se trata es que el concursante entregue el mayor número con la mayor cantidad de iteraciones.

Cabe señalar que si hay más de un programa que llega al máximo valor, ganará quien lo haya enviado primero. El resultado es inapelable.


Al ganador (si es de la Ciudad de México), le daré una taza con el logotipo de la Morsa. Si es de otro país o de provincia, le mandaré un USB de al menos 8 GB. La razón de esto es que mandar una taza por mensajería es estúpidamente caro.

Las soluciones me las pueden mandar a morsa@la-morsa.com.

Cabe señalar que este concurso busca simplemente alentar el trabajo de la programación y mostrar que puede ser lúdica. Es un concurso de buena fe. Si hay, por ejemplo, dos o más respuestas que den el mismo tiempo al procesar la lista de 10 mil números, ganará quien la haya mandado primero. El ganador cede su código fuente a la comunidad. Es decir, se promueve el código abierto.

En este caso no hay restricción en qué lenguaje usar. El concursante tiene que mandar su código fuente, el ejecutable (si aplica) y los resultados obtenidos. El concurso tendrá una vigencia de unas tres semanas, aproximadamente. Así que manos a la obra, digo, dedos al teclado…

Ps. El concurso anterior (sobre la conjetura palindrómica) se ha cerrado y en unos días pondré quién fue el ganador. Estén atentos.

Thursday, May 19, 2016

Programación lúdica: escriba un intérprete de Pilot



Pilot (Programmed Instruction, Learning, or Teaching) es un lenguaje simple, muy simple, de programación, el cual fue desarrollado en los años 60s del siglo pasado. Su idea era automatizar algunos sistemas para enseñanza/aprendizaje. A este tipo de programas se les llamó en su momento CAI (computer-assisted instruction). Fue desarrollado por John Amsden Srtarkweather, un profesor de psicología de la Universidad de California (San Francisco), su intención era la creación de pruebas de aprendizaje automatizadas llamadas "Computest".

La sintaxis de Pilot es casi trivial. Una línea en Pilot contiene (de izquierda a derecha), los siguientes elementos sintácticos:


  • Una etiqueta (opcional)
  • La letra de un comando
  • Una letra opcional Y (yes) o N (no)
  • Una expresión condicional opcional entre paréntesis
  • Dos puntos
  • Un operando o múltiples operandos delimitados por comas


Una etiqueta puede estar sola en una línea, sin necesariamente tener más código. La sintaxis para la etiqueta es un asterisco seguido de un identificador (una cadena alfanumérica con una letra como símbolo inicial).

Los posibles comandos son:

R - Las líneas que comienzan con R: indican un comentario que explica en general el código.

A - Acepta la entrada de datos del teclado, por ejemplo:

 R:La siguiente línea de entrada reemplaza el contenido del búffer de datos aceptados
 A:
 R:La siguiente línea acepta una respuesta del teclado y queda en la variable 'FREE'
 A:$FREE
 R:Las siguientes tres líneas de entrada se asignan a las variables 'X', 'Y' y 'Z'
 A:$X,$Y,$Z
 R:Una entrada de datos numéricos se define así, que en este caso queda en la variable "Q"
 A:#Q

C - calcula y asigna valores numéricos. La implementación original de Pilot sólo tiene aritmética entera (y no hay arreglos). Por ejemplo:

 R:Sacar el promedio de #X y #Y en #AM
 C:#AM=(#X+#Y)/2

D - Permite dimensionar arreglos en algunas implementaciones. Para este ejercicio no hay que hacerlo.

E - End. Regreso de una subrutina, o si es fuera de una subrutina, es el fin del programa. No se usa con operandos.

J - Brinca a una etiqueta. Por ejemplo:

 J:*RESTART

M - Verifica la cadena aceptada en la entrada de datos contra una variable o una cadena de caracteres. Por ejemplo:

 M:TRUTH,$MEXICO,YOUTH

Se regresa 'yes' o 'no' dependiendo si las dos variables son iguales o no. Cualquier instrucción que tenga una Y seguido de una letra de comando es procesada si

N - Equivalente a TN

R - para comentarios

T - Operando Type como salida. Ejemplo:

 R:Manda una cadena a la salida
 T:Gracias por su apoyo.
 R:Manda una variable a la salida
 T:Gracias, $NAME.

U - Haz una llamada a una subrutina. Esta empieza con una etiqueta y termina con un comando E:. Por ejemplo:

 R:Llama a la subrutina empezando en la etiqueta *INITIALIZE
 U:*INITIALIZE

Y - Equivalente a TY (que se usa cuando el resultado de un condicional es Y(es))

Un programa ejemplo:

T: Hello, welcome to my program. Please enter a number
A: #num
C: #ans = #num + 7
T: You entered #num. #num + 7 = #ans


Como puede verse, la creación de un intérprete que ejecute programas escritos en Pilot no parece ser muy complicado. Una taza de la Morsa al que implemente mejor este pequeño lenguaje que, desde luego, parece verse superado ante otras muchísimas iniciativas. En cualquier caso es un ejercicio sencillo pero interesante, el cual plantea algunos elementos que deben contemplarse cuando se escriben intérpretes.



Referencias:

Wikipedia 
RPilot 
Byte Magazine (How To Write a Language in 256 Words or Less) 

Tuesday, April 19, 2016

Programación lúdica: Compresión de una imagen de alto contraste


Las imágenes, los videos, son parte fundamental del cómputo actual. Muchísimos sitios web usan videos e imágenes para ilustrar los temas de interés. Es claro que parte de esta tendencia se debe a que el ancho de banda de la red ha mejorado considerablemente y enviar información de video -entre otras- ya no resulta tan lento. Sin embargo, siempre se agradece cuando por ejemplo, en un sitio web, éste está hecho de manera tal que carga rápidamente y que no saturan de imágenes de mucha calidad (que ocupan desde luego mucho más espacio).

Así pues, a pesar de los avances en comunicación y de que hoy por ejemplo, se prometen 200 Mbits/seg. dados por ciertos proveedores, es claro que este avance se debe precisamente a que hoy recibimos/enviamos mucha información que hace algunos años y esto ha hecho crecer las necesidades de poder guardar todos estos videos e imágenes que nos interesan. Por ello, en ocasiones es importante comprimir información para que usemos menos disco duro pues la experiencia general indica que no importa cuanto almacenamiento tengas, tus datos terminarán llenándolo todo.

De hecho, el formato JPG (o JPEG) y TIFF son formatos con compresión de datos. Los archivos mp3 igualmente comprimen información. Los archivos de video usan diferentes esquemas de compresión también. Por ello, el reto de la programación lúdica en esta ocasión es el de tomar una imagen en alto contraste (en un momento explico cómo se hace eso), y lograr la mayor compresión posible. Es decir, si el archivo original es de -digamos- 300Kb, el ganador del reto será quien pueda reducir, comprimiendo la imagen, en mayor porcentaje. El programa ganador debe poder comprimir y descomprimir la imagen, regresándola a la original (en alto contraste). Es decir no se vale hacer "lossy compression" (o compresión con pérdida, que se explica más abajo).

El alto contraste en una imagen es que sólo tenga dos colores, blanco y negro. Para convertir una imagen a este formato, lo que hay que hacer es tomar cualquier imagen en color, pasarla a tonos de gris. Este funciona así: se lee cada pixel y se hace la siguiente operación: Gris = (Rojo + Verde + Azul) / 3. La división debe ser entera. En el pixel leído se coloca en cada componente de color (Rojo, Verde, Azul) el mismo valor de gris, así, el pixel ahora tendrá como valores (Gris, Gris, Gris). Esto significa que solamente puede haber 256 tonos de gris, desde (0, 0, 0) hasta (255, 255, 255). (Ojo, usamos el modelo RGB, Red, Green, Blue).

Una vez que se ha transformado a tonos de gris la imagen, para pasarla a alto contraste, lo que se hace es simple: se toma cada pixel de la imagen en tonos de gris: Si cualquiera de los componentes de cada pixel es arriba de 127, pongo un blanco (255) y si es menor de ese valor pues pongo un negro (0). Así, si el pixel de entrada es (34, 34, 34), el de salida será (0, 0, 0). Si el pixel de entrada es (192, 192, 192) el de salida será (255, 255, 255).

Teniendo la imagen en alto contraste, el siguiente paso es comprimirla. ¿Cómo puedo hacer eso? Hay muchas técnicas. Mencionaré una pero ojo, no es necesariamente la que hay que programar, puede ser cualquier técnica que comprima imágenes y quizás la que el lector que le entre al reto, si es la mejor, se llevará el premio. He aquí un simple ejemplo: Tómese una imagen y empiécese a leer cada pixel de la imagen en alto contraste. Si la imagen empieza con esta secuencia: 255, 0, 0, 0, 0, 0, 255, 255, 255, 255, 255, 0, 0, 255, 255, 255, 0, ... entonces nosotros crearemos un archivo que contenga el valor del pixel y un contador que mide la cantidad de veces que ese valor se repite. Así, pondremos 255|1, 0|5, 255|5, 0|2, 255|3, 0|1... este tipo de compresión se llama RLE (Rule Length Encoded) y funciona mejor en imágenes donde hay muchas zonas donde se repiten los mismos colores (no necesariamente sirve para hacerlo en alto contraste). Obviamente, si tenemos una imagen en donde cada pixel cambia de valor, entonces la "compresión" RLE nos creará un archivo del doble de tamaño. Este es el código ejemplo en Delphi para comprimir un archivo en general (no necesariamente de una imagen) usando RLE:


La rutina que descomprime es ésta:




Repito: la compresión RLE es una posibilidad, pero se puede usar cualquier otro método de compresión.

Hay sin embargo, otros esquemas de compresión que pierden información, y se denominan "lossy compression". Esto significa que al comprimir se pierde información de la imagen original y al descomprimirla, tenemos una imagen ligeramente alterada. Quizás el ojo humano no distinga las diferencias pero las hay. En este reto no se vale hacer compresión lossy, es decir, la imagen comprimida debe descomprimirse en la imagen original de manera idéntica.



El programa debe poder cargar cualquier imagen JPG en color y pasarla a alto contraste, guardarla (para saber de qué tamaño queda) y procesarla, para poder comparar contra la imagen original y hallar el promedio de compresión.

El ganador se llevará una taza de la Morsa. Si vive fuera de la ciudad de México el premio será un USB de al menos 8 GBytes. El costo de mandar una taza fuera de la CDMX que es donde vivo es unas 10 veces el costo de la taza, lo cual es ridículamente caro. Si alguien quiere la taza de todas maneras, lo que podemos hacer es que le mande el logotipo de la misma y se la haga en OfficeMax y yo pago el costo de ello (que es menos de 100 pesos). Quiero aclarar que más allá de algunos apoyos, no tengo patrocinios para este tipo de concursos. Si logro que alguna empresa me ayude con el envío de la taza al ganador, pues con gusto se la hago llegar. Así pues, si me van a criticar por esto, mejor hagan lo inverso, apoyen la iniciativa de la Programación Lúdica, por favor.

El ganador será quien pueda comprimir en mayor porcentaje la imagen de Ilse (ver más arriba). Si hay dos o más programadores que lograron el mismo porcentaje y son los mejores, es decir, si hay empate, el primero que haya mandado la solución será el ganador. El código debe estar razonablemente comentado para ser leíble. Se agradecerá también una breve explicación del método usado.

Les recuerdo que estos concursos se hacen de buena fe. La idea es promover que la gente programe y que genere código. Cabe decir que el código que escriban pasa a código abierto como parte de las condiciones para concursar. La cuestión es que todos aprendamos algo en este c camino. El concurso tendrá una vigencias de unos 20 días, máximo un mes, para poder mandar los resultados.

¿Dudas? ¿Comentarios? A mi correo: morsa@la-morsa.com.

Gracias

Wednesday, May 20, 2015

Para ganar en el reto de los fotomosaicos


El reto de crear un programa de fotomosaicos inició el 11 de mayo y terminará el 11 de junio a las 12 de la noche. Vamos, al día siguiente (12 se junio) ya no aceptaremos ninguna participación. La colección de fotos se ha bajado 51 veces hasta este momento y si quitamos aquellos que quizás bajaron las fotos para tener una buena colección de las mismas, quizás estemos hablando de unos 30 o 35 interesados en desarrollar el software propuesto.

Cabe decir que el video y las explicaciones para hacer un fotomosaico que pueda participar en el reto son las mínimas aceptables, pero desde luego, cada programador bien podría buscar mejorar su algoritmo y hacerlo más sofisticado, más elaborado para así ganar el iPod Touch. Por ejemplo, una imagen de un interesante mosaico puede verse aquí:


Si observamos con detenimiento veremos que el autor no usa una cuadrícula, sino que desfasa los mosaicos como si fuesen tabiques en una pared. Es decir, para construir una pared no apilamos un tabique encima del otro, sino que hacemos una fila de tabiques y en la siguiente línea de tabiques, los desfasamos a la mitad de la fila original. El resultado es éste:


Esto parece ser que mejora la apariencia final del fotomosaico. Nótese en particular que en la imagen de Bobby Fischer hallamos que ciertas imágenes parecieran que tienen las sombras exactamente donde deben tenerlas, por ejemplo en el caso de la nariz, en los costados, aparece la imagen de un tablero que lleva la forma de la nariz por donde respiramos. O el autor puso esa imagen sin querer y le pasó como el burro que tocó la flauta o bien, está haciendo otra cosa.


Me di a la tarea de averiguar esto y me escribí un programa que lo que hace es pasar una imagen a tonos de gris para así poder después calcular un umbral máximo de colores. De los experimentos que hice, me da la impresión que el autor de este fotomosaico usa muy bien el blending sobre la imagen original aunque pareciese que reconoce formas para saber qué tipo de imagen poner. Desde luego es necesario hacer un análisis más cuidadoso.

Pero aparte de este fotomosaico de ejemplo, hay quienes han desarrollado otras técnicas, por ejemplo, éste:


Obsérvese que aquí los mosaicos son de diferente tamaño. Esto hace que el resultado final sea muy diferente a un fotomosaico hecho simplemente colocando una malla cuadriculada.

Nótese por ejemplo este otro y analícese:



Podrá notar que parece un fotomosaico del logotipo de Apple normal, pero cuando nos vamos acercando a los límites de la imagen, se empiezan a poner fotos más chicas. Esta idea de hacer fotomosaicos con una malla irregular suena muy interesante y entiendo que requiere de mayor programación. Uno de los mosaicos más interesantes con esta técnica es el de Steve Jobs, hecho con el programa de Artensoft (ver la ilustración inicial de este artículo).

Una imagen de Ilse con este programa puede verse aquí:


Se usó la misma colección de fotos que los que le entren al reto deben usar. Para probar, descargué la versión gratuita de Artensoft para ver qué tantas opciones me daba. Es una interesante aproximación y vale la pena que la descarguen porque da buenas ideas. Vamos, Artensoft también tiene su propio algoritmo para que no se repitan las imágenes.


Finalmente, es recomendable echarle un ojo a la versión electrónica del artículo del Dr Dobbs Journal (noviembre 2001), en un artículo que escribimos Marcelo Pérez Medel y yo, llamado "Your Own Photomosaic Engine!".

Saturday, May 16, 2015

Programación lúdica: más información sobre cómo hacer los fotomosaicos


Luis Marcos Rivera es un ingeniero técnico en topografía, nacido en España, con una maestría en geotecnologías en ingeniería y arquitectura. Aparte de esto, es programador y sin duda un apasionado de la tecnología. Hace un par de días Luis me mandó su programa para hacer fotomosaicos. He aquí lo que me escribió:  “Más que participar (ya que no resido México), simplemente quiero aportar mi idea y mi código como moneda de cambio porque, gracias a la entrada que hiciste hice el programa que te pasé. Sé que no se ciñe estrictamente a las bases, pero principalmente mi propósito es el poder compartir código ;)”.

En su blog comenta lo que hizo y pudiese ser una ayuda a quienes quieren entrar en este reto. Cabe decir que Luis ha donado su código fuente y se vale revisarlo, más no copiarlo, porque por una parte, es fácil que me dé cuenta de ello y por otra, que no se trata de copiar código de terceros, sino de hacer su propio sistema de fotomosaicos, independientemente de poder o no ser el mejor y ganar el premio.

Luis me mandó tres imágenes de Ilse fotomosaiqueadas. La primera (izquierda), la original. La segunda (en medio) con blending y la tercera (derecha), queriendo evitar las repeticiones. Compárese estas imágenes con las mías -de nuevo, izquierda sin blending y derecha con blending. Por otra parte, Luis intenta resolver el problema de las repeticiones de manera ingeniosa, aunque en mi opinión, falta elaborar un poco en este asunto particular.

Imágenes de Luis



Imágenes de La_Morsa

Sugiero bajen las imágenes originales de Luis, que ocupan muchos megas, pero que le dan muy buena resolución a los mosaicos creados. Aquí los he reducido porque no puedo poner imágenes de megabytes. La liga es ésta.

Veamos el video de Luis al respecto de su software:



Cabe decir que un fotomosaico no necesariamente es mejor porque ponga la mejor imagen en cada región de color que tenga que sustituir. Muchos mosaicos. Por ejemplo, dos imágenes que ilustran este artículo demuestran esto. La primera es del payaso de la TV, Brozo (ilustración que encabeza el artículo), cuya foto es muy buena para hacer fotomosaicos porque es muy colorida. Nótese que esta foto tiene muy poco blending. La segunda foto es en mi opinión, un fotomosaico hecho con un algoritmo más sofisticado con respecto a las repeticiones. Se trata del excampeón mundial de ajedrez, Bobby Fischer. El autor del mosaico es Paul Van Scott, de Palm Bay, Florida. Nótese que la foto original es blanco y negro pero el autor del mosaico usa incluso fotos a color. La razón de esto es que -probablemente- cada foto en color puede ser parecida a un tono de gris cuando se ve ya desde muy lejos o habiéndola reducido en tamaño considerablemente. Como sea, claramente este mosaico me parece superior por la variedad y la manera de evitar las repeticiones. Da las impresión de usar blending, pero no puedo asegurarlo. Este es uno de los mejores trabajos que he visto.




Referencias:

Blog de Luis