Igual la pregunta os suena absurda, pero que es que noes esta pasadno algo muy extraño con los pngs, tenemos 3 pngs que son 3 strips, osea imagenes con los distintos frames de una misma animacion, total que la animacion tiene 13 frames de acuerdo?
Hicimos un primer strip de 4x4 dejando 3 huecos libres, resolucion de 2400x336 que ocupa 471 kb, como habia mucho hueco libre pense en que podriamos buscar una forma de hacerlo para que no hubiesen huecos libres y asi en teoria, reducir el tamño de la imagen, y aqui viene el problema, uno de 1x13 de resolucion 600x1092 pesa 534 kb!
Hicimos otra prueba para ver si algo intermedio podiamos ahorrarnos mas kb, y hicimos uno de 5x3 dejando asi solo 2 huecos libres y usando menos resolucion que en el primero 1800x420 pero mas que en el segundo y el resultado fue 477kb
Alguien me puede explicar cuando exactamente pesa mas o pesa menos un png para buscar la mejor forma de almacenar las animaciones de mi juego?
- los pngs...bueno, también depende con que software los grabes. Y en muchos softwares, tienes un setting para decirle el nivel de compresión que quieres. (por ejemplo, en irfan(irfanview.com) , ponle 9, la máxima)
-multiplica alto por ancho y el resultado en pixeles, pues es un indicativo de la memoria que vas a ocupar, en principio (según el código, hay veces que da igual a nivel interno, sólo importa a veces esa multiplicación) , pero hay muchos más factores. PNG usa una especie de compresión lossless, o sea , sin perdidas de calidad, muy parecida a la del zip. Pero..se aplica tb a la imagen, puntos todos de un mismo color, da muchísima más alta compresión. Mientras que imagenes detalladísimas dan una compresión muy mala.
-cuida que no estés realizando en alguna de las grabaciones una compresión con pérdidas.O sea, reducción de colores, con cualquier fltro en el mismo diálogo de grabación del png. puede pasar.
-los programas, además de que no todos graban con la misma compresión, los hay mejores y peores, puedes tenerlos además configurados en el salvado a png de distinto modo.Haz la prueba siempre con el mismo programa(irfanview es jodidillo pa la transparencia...)
-no hay magia, pero no me hago una idea exacta de cuales son las imágenes que comparas, si no, te diría seguro lo que pasa.
-existen una serie de programas que comprimen muchísimo más el png de lo que estás comprimiendo tú con los programas standard. S lo puedes pasar al final, aunque algunas cosas, como quitarles chunks innecesarios de la cabecera, no se notan realmente si no estás haciendo cosas para móviles, donde cada byte cuenta...
Por ejemplo, pngcrush(recomendado), tweakpng (este sirve para quitar o escribir comentarios), pngGauntlet, superpng, etc...
http://pmt.sourceforge.net/pngcrush/index.html http://sourceforge.net/project/showfiles.php?group_id=1689
http://optipng.sourceforge.net/
http://brh.numbera.com/software/pnggauntlet/
http://www.fnordware.com/superpng/
http://entropymine.com/jason/tweakpng/
Te recomiendo pngcrush(aunque sea de msdos(consola en xp)) y tweak png.
en 256 colores ocupan muchísimo menos, pero es meterte en muchas limitaciones, en juegos para pc, no te lo recomiendo. si reduces con dispersion o cualquier otra trama, será más memoria al grabar, claro. A menudo es inevitable. Si fueran de muy baja resolución(64 o 32) los tiles, si te recomendaría 256 colores o menos, sin dispersion.
-espero que la comparación no la hagas cambiando el tamaño en pixeles de cada tile cada vez! No es en absoluto lo mismo si cada tile mide 64x64, que 128x128, el resultado de la multiplicación es lo que cuenta, en principio, aunque ya te he dicho que luego hay que considerar todos los demás factores, y sobre todo, la complejidad de la imagen.
Un png a dos colores, blanco y negro, guardado como 4 bits, puede tener miles y miles de pixels (hice la prueba hace años de slavar un texto larguísimo así) puede ocupar una cantidad muy ridícula de memoria.
Si desarrollas para juegos pc, de todos modos, no te interesa perder calidad ahí.
y un apunte, si el PNG tiene alpha el algoritmo de compresión la utiliza para desechar zonas, eso quiere decir que si la zona nula de tu png la pintas con alpha cero entonces no ocupará casi nada ya que recorta la imagen (esto a veces es una putada porque si quieres conservar la información RGB en las zonas con alpha 0 no puedes.
interesante eso tamat, no tenia ni idea de que tambien hacia eso
Pues mi caso es el siguiente, estoy produciendo/codeando un juego shareware y necesito pngs a tope de calidad y usando alpha, que programas de los que me has mencionados antes seria el mas recomendable para mi caso?
Los compresores casi todos mantienen el alpha. El irfan...sí, las últimas versiones, pero da problemas a menudo, si tienes alpha no lo recomiendo.
Pero para trabajar en sí: Adobe Photoshop, Paint Shop Pro, y Gimp.
Los compresores son para el último toque.
Mmm, me parece que no me he explicado con claridad, me referia a que programa para comprimir el png me recomendarias en mi caso...
No me he metido todavia muy a fondo con el formato, pero una vez que le eché un vistazo por encima ví que el PNG utiliza mucho el concepto "scanlines" a la hora de comprimir. Es decir, comprime cada línea horizontal como unidad mínima de información. ¿Podrías hacer la prueba con tu animación a 13x1 a ver lo que sale? Quizás menos scanlines signifiquen menos tamaño en algunos casos.
un saludo
Gracias donald por la info y los links!
A modo de comentario:
Hice una prueba con un png que tengo para móviles. Es una imagen de 240 x 224 y una resolución de 72 px.
En la imagen hay varios frames de distintos sprites.
Uso una paleta de hasta 64 colores y tiene transparencia.
Está diseñada en Photoshop CS y guardada para web como PNG-8 y Perceptual.
La pasé por el pngcrush (no lo conocía) para ver qué mejoraba. Utilicé la option de fuerza bruta, para que use todos los algoritmos. No me comprimió ni un sólo byte extra.
Saludos!
Yo uso el photoshop cs como tu chechocossa y no se que hace, pero comprime los pngs que da gusto, por el momento no he encontrado aplicacion que me deje los pngs tan reducidos como el, no obstante hechare un vistazo a toda la info puesta por este hilo, por que 100bytes en un .jar son mucho :wink:
Cita de: "fiero"No me he metido todavia muy a fondo con el formato, pero una vez que le eché un vistazo por encima ví que el PNG utiliza mucho el concepto "scanlines" a la hora de comprimir. Es decir, comprime cada línea horizontal como unidad mínima de información. ¿Podrías hacer la prueba con tu animación a 13x1 a ver lo que sale? Quizás menos scanlines signifiquen menos tamaño en algunos casos.
Tomando en cuenta lo que dijo fiero, hice una prueba en Potoshop CS cambiando de lugar los frames, para que en cada línea de frames sólo haya imágenes pertenecientes al mismo sprite (todos colores parecidos)
No me importó dejar algunos huecos en otras líneas de frames.
En la versión original, el png resultante era de 6.112 bytes. Con la modificación, quedó en 5.978 bytes = 134 bytes menos.
Saludos!
No tengo ni idea de como trabaja el png, pero por si vale de algo... estas dos imagenes estan hechas con el photoshop cs, modo perceptual:
1211 bytes
(http://img453.imageshack.us/img453/3843/capsulesh7yk.png) (http://imageshack.us)
1137 bytes
(http://img391.imageshack.us/img391/3820/capsulesv9so.png) (http://imageshack.us)
Como siempre tengo la imagen que contradice la regla :?
Editado: Pues creeme estaba haciendo la imagen para secundar lo que habias puesto, por que si no creo que recordar mal muchas veces hacia lo que decias para ahorrar espacio en disco.
zupervaca, no puede ser que vengas a rebatir lo que tanto me costó descubrir :P
Será tal vez que al generar el png, analice si hace un scan horizontal, o vertical, o algo parecido, hasta encontrar el mejor porcentaje de compresión...
De todos modos, habría que leer sobre el tema, cosa que no haré ni mucho menos por ahora 8)
CitarMmm, me parece que no me he explicado con claridad, me referia a que programa para comprimir el png me recomendarias en mi caso...
PNGCrush...Es que te lo había dicho ya en el otro post, por eso no creí que te refierieras a eso ;)
@checho.. Erm.Sí que debe comprimir más...bastante más. Deciros que esto no es una ciencia exacta. Depende de la imagen y tal.
creo que tepuede estar pasando...que...no tehas leído bien a fondo del todo ese pedazo de readme del Pngcrush...usa la versión última, si puede ser una con soporte MMX....
Una buena señal es que con todos los settings, para los graficos de un juego típico de móviles, se tire un ratito procesando para hacer las compresiones...
brute force, pero un puñado de settings más...leetelo bien...de todos modos....Un consejo, no basado en la ciencia, si no la experiencia... ;)
No cmprimas desde un ya salvado png por "salvar como web" , sino que...guarda normal como PNG desde adobe, en guardar como...creo que era así, si lo estabas probando al reves, prueba ahora lo contrario...
Lo que sí te digo es que funciona, vaya si funciona...y en móviles...es un ventajón...ya te digo, habrá gráficos en que la ganacia sea muy pequeña, pero muchos te dejarán ganar mucho más...
Y luego, el Tweakpng(pasadlo ANTES de pasar el compresor, el compresor, lo último) os sirve para quitar comentarios innecesarios...No dejesi de mirarlo!! Porque a veces esos chunks de texto suponen más bytes o ks de la cuenta, que no quereis para nada...ya te dice el tweak que es crítico y qué no...
Por algún lado leí que otro comprimía más, no sé si el gauntlet...el optipng...pero a mí el que más me comprime es el pngcrush...Eso sí, es msdos, o sea, hay que hacerse idóneamente un *.bat, y poner los settings, los parametritos (/b /f , lo que sea) y hacer trial y error hasta que veas que te da buen resultado. Yo es que no tengo a mano los settings, pero vaya que son los mismos, siempre. Hay unpuñado de parámetros que son los que te dan la cmpresión mayor.
CitarEstá diseñada en Photoshop CS y guardada para web como PNG-8 y Perceptual.
Puedes tener un resultado parecido, aunque menos flexible, simplemente pasando a indexado con el menu modo en adobe , y luego salvas como png, no hace falta salvar para web, lo digo por hacer la prueba de que salvar para web es que no permita recomprimir luego o algo...
perceptual...o sea, usas error difussion. Eso es un entrelazado (no de carga, de imagen) eso es que coge los 64 colores y hace tramas...a veces, da como resultado tramas sucias, pero el grado de trama en salvar para web se puede cambiar. A menudo, más colores y sin trama es menos memoria, puedes probar eso, porque la trama puede hacer muy dificil que se produzca buena compresión, supongoq poque no hay grandes areas iguales...
es la puñetería de tener que guardar las cosas en un bitmap con todos los frames...sería tal vez menos memoria si se pudiera guardar independientemente, pero igual las cabeceras de los archivos...no, no he dicho nada...ni tampoco que los graficos de paleta similar fueran los agrupados...para código o rendimiento esas cosas serían una barbaridad.
Imaginaros una gran imagen de hiedra...es todo verde. Ahí 32 colores(incluso 16) dan una sensación de realismo total, con difussion. Ahora cogeis un set de sprite, con personajes con colores de ropa distintos, caras, etc...ni 64 colores darán un resultado ideal.
Un png a 24 bits, puede comprimir una barbaridad con el pngcrush...salvar el 40% en algunos casos, no es desdeñable...en desarrollos pc, quiero decir.En móviles, ya sabeis que saques los ks que saques (pero se pueden ganar muchos, depende del caso) que ganan puede ser que te lo acepte o no la operadora ;)
Aunque ya le dije esto a Josepho por MSN, lo pongo aquí por si alguien tiene algo que decir.
@Josepho: si lo que quieres es tener la mayor calidad de imagen y a la vez que el instalador ocupe lo mínimo (no así el espacio en disco una vez instalado), te recomiendo que utilices un formato de imagen sin compresión. Una opción sería un BMP para el RGB y otro en escala de grises para el alfa (estilo PopCap Framework), pero esto es más coñazo y yo recomiendo TGA sin compresión.
Esto hace que el espacio en disco una vez instalado sea mayor, pero un programa de creación de instaladores tipo Inno Setup, para comprimir realmente bien (usa LZMA que va de coña aunque tarda lo suyo y chupa mucha RAM al crearlo) necesita datos no comprimidos. Usa BMP, TGA, WAV, etc donde puedas. Por ejemplo, para samples usa WAV, mientras para música utiliza mejor OGG que aunque lleve compresión tiene la ventaja de que luego lo cargas como un stream en el juego y no te ocupará mucha memoria. Sin embargo las imágenes no proporcionan este beneficio y no vale la pena.
Yo recuerdo que pasando todas las imágenes del Cursed Wheel, que no tenía muchas, de PNG a TGA sin compresión, el instalador bajó de 11 MB a 8, mientras que el tamaño sin compresión aumentaba bastante.
yo creí que él estaba obligado de algún modo a usar PNG.
Sí, eso tiene mucho sentido.
Aunque...depende...quien sabe ;) (no he hecho una comparación con imagenes RGB y png con pngcrush)
En cualquier caso, lo del instalador comprimiendo mucho, es lo menos engorroso, y cada ganancia de tu tiempo cuenta :)
De todos modos, igual es también bueno porque no sé si es perceptible para un Pc, pero supuestamente, el PNG tiene que descomprimir al abrirse...no tengo números al respecto...
Yo he usado las 3 técnicas , bmp con grises, el transparency del png, y el tga con alpha channel. Por cierto, es más enrevesado, pero el Gimp lo hace correctamente.
Por cierto, el 7-zip comprime muchísimo.
Teniamos un hilo sobre eso hace unos meses, con pruebas y medidas y tal. Lástima que no funcione la herramienta de búsqueda del foro.
Ratifico lo que ha dicho Colsón. PNG internamente usa el algoritmo de compresión deflate (el de los .ZIP) que es inferior al LZMA que puedes usar en un instalador (el SDK LZMA es libre y puedes hacerte tu formato de archivo empaquetado con LZMA para el juego en lugar de depender del instalador).
Solo añadir que PNG es más que el compresor, ya que el formato internamente tiene filtros y reordenamientos de los pixeles previos a la compresión. Esto hace que comprima más en ciertos casos debido a que técnicamente ya no está comprimiendo la misma secuencia de bytes.
Para usarlo en BlitzMax, pues eso, TGAs y tirar del instalador, pero para el que programa en C++ y no necesita fidelidad 100% sigo defendiendo descomponer la imagen en 2: una RGB en JPEG y otra del ALPHA en RAW con compresión LZMA. EL programador que las combine en memoria.
Dado que el alpha se comprime sin perdida, al aplicarlo en pantalla enmascara los posibles defectos en el sprite que pueden dar los bordes duros en JPEG. Hablo de usar realmente los 32 bits de color, no de cartoon, claro.
Un problema de los TGA no podria ser que luego chupara mucho mas memoria de video y bajasen los fps del juego? No stoy muy al dia en esto por eso pregunto...
Independientemente del formato que uses de compresión, una ves los cargues para mostrarlos ocuparán lo mismo en memoria (salvo que uses compresión de texturas en la gráfica).
Cita de: "ethernet"Independientemente del formato que uses de compresión, una ves los cargues para mostrarlos ocuparán lo mismo en memoria (salvo que uses compresión de texturas en la gráfica).
¿ Las texturas permanecen comprimidas en memoria de video ? Pensaba que solo se comprimían para reducir consumo de ancho de banda al subirlas a la tarjeta, pero que la grafica las desempaquetaba en memoria de video.
Me encantaría ver algún link que lo corrobore, ya que encaja con el hecho de que para render target no te valga usar una textura creada de forma normal (aunque coincida en profundidad de color).
Esto ya es offtopic para general grafistas, que no nos coma la yakuza :P
Cita de: "senior wapo"
¿ Las texturas permanecen comprimidas en memoria de video ? Pensaba que solo se comprimían para reducir consumo de ancho de banda al subirlas a la tarjeta, pero que la grafica las desempaquetaba en memoria de video.
Me encantaría ver algún link que lo corrobore, ya que encaja con el hecho de que para render target no te valga usar una textura creada de forma normal (aunque coincida en profundidad de color).
Esto ya es offtopic para general grafistas, que no nos coma la yakuza :P
No lo sé, lo he asumido y la verdad es que no sé porqué. En http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_compression.txt
pone : "Compressing texture images can reduce texture memory utilization and improve performance when rendering textured primitives", lo cual parece que viene a decir que permanecen comprimidas.
También si miras la página de la wikipedia ( http://en.wikipedia.org/wiki/S3_Texture_Compression ) pone que provee acceso rápido a los pixels, lo cual tb apunta a que permanecen comprimidas, aunque, cuando he dicho eso lo he dicho sin pensar demasiado.
Poseso que si uso TGA usara mas memoria de video no? Con lo cual menos compatibilidad con tarjetas viejas no? O igual es que no lo he entendido bien..
Cita de: "Josepho"Poseso que si uso TGA usara mas memoria de video no? Con lo cual menos compatibilidad con tarjetas viejas no? O igual es que no lo he entendido bien..
En la práctica, da igual el formato de fichero que tengas en disco, cuando las cargues en memoria van a ocupar lo mismo.
Cita de: "Josepho"Poseso que si uso TGA usara mas memoria de video no? Con lo cual menos compatibilidad con tarjetas viejas no? O igual es que no lo he entendido bien..
No, una vez has cargado la imagen en memoria da igual BMP, PNG, TGA, JPG o lo que quieras. Eso sólo son formatos para guardar la imagen en un fichero, una vez la has cargado en memoria RAM, la imagen ocupará ancho*alto*bytesPorPixel = bytes totales, da lo mismo en qué formato estuviera almacenada.
Para ocupar menos RAM se puede variar el numero de bytesPorPixel al almacenarla en RAM, es decir, 24, 16 ó 8 bits. O también se puede utilizar compresión de texturas, pero eso sólo aplicable a gráficos 3D y no compatible con todas las tarjetas.
un saludo
Que yo sepa, permanecen siempre comprimidas, al menos en S3TC y el resto de DXT, que nunca sabe uno cuando salen tecnicas nuevas...
Lo mejor en pc, tal como comenta el senior wapo, es hacerse un formato propio, eso si te lo quieres/puedes permitir en tiempo.
Yo no soy muy amigo del jpeg pero sabiendo ajustar la compresion se puede salvar mucho disco.
Retomando este post antiguo...
El mejor parece ser PNGOUT, programado por el chaval que con 19 años hizo el Duke Nukem 3D Jejeeje. Gana a sus competidores más cercanos, como OptiPNG, PNGCrush y otros que habeis comentados.
http://www.codinghorror.com/blog/archives/000810.html
Por cierto Josepho, ¿cuál era ese formato rarillo-png que elegiste al final que me comentaste hace tiempo?