25meneos
Convierte imagenes en archivos html+css
img2xhtml es una utilidad para GNU/Linux que dada una imagen, genera un archivo html+css que pinta exactamente la misma imagen contenida en el archivo original, para ello, crea pequeños elementos xhtml de 1 pixel, y utiliza varias técnicas de optimización para reducir su tamaño.
negativos: 0 usuarios: 22 anónimos: 3 compartir: 
menéame
- condiciones legales y de uso
- quiénes somos
- licencias: código, gráficos, contenido
- descargar
- alojamiento en Ferca Network
Personalmente me encanto la optimizacion... ;)
Edit: vale, entendí mal el comentario xD
Seguro que el próximo gimp es vía web xD
Por ello, lo mas fácil es ejecutar el binario compilado con optimización etc, y leer su salida desde php, por ejemplo.
Aunque sería interesante hacerlo en PHP, temo que no escalase mucho, por ejemplo, una técnica que estoy probando para reducir mas aún los pixeles, es jugar con áreas muy densas en x color, crear allí un cuadro detras, y no pintar ciertos pixeles.
Solo para crear una estadística de la densidad de áreas, en C tarda 2-3-4 segundos, depende, imaginalo en Java, no lo veo viable, aunque quizá me equivoque.
Edit: posteo el code en pastebin: pastebin.com/f16b905fe
0.04 segundos teniendo en cuenta el paso por Apache, lo que tarde wget en enviar y recibir cabeceras... Pero bueno, dejémoslo en 0.04s.
Con java, obviamente, rularía mucho más rápido. Si mañana tengo tiempo en el curro lo pruebo.
real 0m0.004s
user 0m0.000s
sys 0m0.002s
jcarlosn@linux-wnp3:~/img2xhtml>
Donde tu has tardado 0.04 (4 centesimas, te parece poco?) el código en C tarda 6 MILESIMAS.
Vale, la diferencia es de: 0.04 frente a 0.006, lo que nos da un total de 6 veces mas, teniendo en cuenta que con operaciones mucho mas complejas, como he comentado de los cuadrados, la diferencia entre el C y el PHP se incrementa muchísimo...
En una imagen grande, donde el C con lo que he comentado tarda 4 segundos, tu tardas 24, eso aun en el mejor de los casos, en el que el PHP no rinde peor que el C en algoritmo... » ver todo el comentario
Veamos, probemos los dos programas en MI máquina (tu tienes un pedazo de maquinón, que nos conocemos ;) ).
Además, he hecho un php que ejecute tu binario y muestre la salida.
Medidos con wget:
mi programa tarda 0.04s
tu programa tarda 0.02s
Sí, tienes razón, es más eficiente el programa creado en C++ (normal), pero no tanto como decias. Además, parsear una imagen tan grande como la que propones es la muerte para el navegador del cliente.
Pero ¿por qué tantas cosas están hechas en PHP y no en C/C++? no es un capricho, es lo que señala #3 (ojo, que ni he probado si tu código funciona en plataformas diferentes a GNU/Linux, no tengo ninguna a mano).
Tu código ha tardado 0.04s, todo el rato ha vivido en PHP, y eso es lo que ha tardado.
Mi código ha tardado, en tu máquina y teniendo que pasar a través de tu PHP, 0.02s, mientras que en ninguna máquina superior a un pentium 4 tardaría eso, ni de broma, solo en ejecutarse el binario.
Entonces, ahora imaginemos que extendemos el programa de forma compleja, en el cual, tu código vivirá siempre en el PHP, mientras que mi programa, sobre tu PHP, sufrirá la lentitud de PHP, entonces se ejecutará el binario, y volve... » ver todo el comentario
dan.corlan.net/bench.html
No voy a pastear el resultado del C optimizado ni del python +psyco, sino las cosas reales:
C, gcc V2.95.4 3.61 3.57
RUBY*** (interpreted) 1074.52
Python** V2.1.2 (interpreted) 505.50
Perl* V5.6.1 (bytecompiled) 515.04
Mira que diferencias, donde C ha necesitado 3.61 segundos, Ruby ha necesitado 1074.52 segundos, te recomiendo que mires:
shootout.alioth.debian.org/
Una web muy buena sobre todo esto, con muchos datos y benchmarks.
Por ejemplo:
shootout.alioth.debian.org/u32q/benchmark.php?t... » ver todo el comentario
Yo también defendía a C++ sobre Java (y lo sigo defendiendo), pero Java tiene muchos ases debajo de la manga.
Mi jefe me hizo ver como un simple for (int i = 0; i < 9999999999; ++i) { int lol = i * i + 50000 + i; } es 7 veces más rápido en Java que en C++. No veas la cara que se me quedó (aún así, sigo defendiendo C++, simplemente por que Java me parece más bien un juguete en algunos aspectos, pero eso ya es carne de otro flame).
Y en referencia a #12:
Ambos coincidimos en que es más eficiente C++ que PHP, pero ten en cuenta el contexto: generar un html que a base de tags <a> construya una imagen.
1. Si está en un servidor de imágenes...
... » ver todo el comentario
Mi jefe me hizo ver como un simple for (int i = 0; i < 9999999999; ++i) { int lol = i * i + 50000 + i; } es 7 veces más rápido en Java que en C++. No veas la cara que se me quedó (aún así, sigo defendiendo C++, simplemente por que Java me parece más bien un juguete en algunos aspectos, pero eso ya es carne de otro flame).
Ahí hubo gato encerrado, mira:
shootout.alioth.debian.org/u32q/benchmark.php?test=allp
mandelbrot ~99 ~2.0 1.3
G++ (el de la ~) es 99 veces mas rápido resolviendo mande... » ver todo el comentario
Fácil. No hace falta que dejes C o C++, usa un recolector de basura (hay varias librerías). Además, en C++ tienes los punteros inteligentes.
Si quieres usar el programa para imágenes grandes, hay sitios del código donde podrías optimizarlo, como por ejemplo las iteraciones de los bucles (a simple vista) no tienen dependencias entre sí. Pasarlo a un algoritmo del estilo "divide y vencerás" para paralelizarlo sería relativamente trivial.
Por otra parte, ¿la libjpeg no tiene nada como mmap()? Lo digo por lo de tener que escanear línea por línea.
"Puedo usar C/C++ sin encargarme yo de la memoria?"
Sino:
"Se puede usar realmente un lenguaje donde la gestión de memoria la haga un interprete (o una capa intermedia), para problemas complejos sobre volúmenes ingentes de datos?"
Eso te pasa por entrar al flame corriendo y sin leer :p
¿Qué flame? De verdad, deberías dejar de tomarte las cosas tan a la defensiva, saltas a la primera :-(
En fin, a la reformulación de la pregunta, te puedo asegurar que sí. De hecho es beneficioso, ¿porqué? Pues porque si creas y destruyes la memoria al momento, tu programa irá más lento (malloc/free y new/delete tienen un coste). Cualquier programa que tenga que estar ejecutándose por largos periodos y que trabaje con muchos datos se verá beneficiado de varias técnicas (pool de memoria, destrucción de objetos demorada, mallocs especializados, etc.)
Acerca de lo que dices...no estoy de acuerdo.
Cuando tienes un lenguaje abstraido, tienes una capa entre tu y la memoria, es una capa genérica, y que tiene un coste, sin embargo, tu propones que es mejor, pero argumentas cuestiones relativas a la implementación.
En primer lugar, cualquier técnica que utilice PHP, el cual está hecho en C, la puedes utilizar tu también en tu programa en C, y con una capa de abstracción menos, lo cual siempre se nota (mira las gráficas que puse mas arriba)
En segundo lugar, de que sirve la destrucción de objetos demorada? toda la memoria que pides, la ha de liberar, sea ahora, o dentro de un rato.
Acerca del pool de memoria, no lo veo claro para una imagen, respecto al impacto que tiene en el consumo de memoria total.
Digo yo, que para grandes volúmenes de datos, además de la gestión de memoria que comentáis, paralelizar también ayudaría, ¿no?, tipo erlang (aunque hablo de oídas, también 'he oído' que la complejidad puede hacerse difícil de manejar si no se lleva cuidado).
Cuando tienes un lenguaje abstraido, tienes una capa entre tu y la memoria, es una capa genérica, y que tiene un coste, sin embargo, tu propones que es mejor, pero argumentas cuestiones relativas a la implementación.
Hablaba de la manera de gestionar la memoria en C y C++ porque era de los lenguajes de los que estábamos hablando. Aún así, manejar la memoria "a mano" no siempre es eficiente:
en.wikipedia.org/wiki/Memory_pool
En primer lugar, cualquier técnica que _uti... » ver todo el comentario