fpg32converter

Started by DCelso, December 10, 2008, 05:06:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

animanegra

Expongo lo que he entendido, si guardo con una paleta de mas de 256 colores me deberia de usar modo rgb. O no exactamente pero lo que ocupe la imagen si que deberia de ser igual o superios a guardando en RGB.

Entonces algo no me cuadra, porque si uso una paleta de 1024 colores para obligarle a usar mas de 8 bits me ocupa menos que el rgb? Pero bastante menos.

animanegra@T0m4t0:~$ ls -al prueba1.png
-rw-r--r-- 1 animanegra animanegra 200 2008-12-11 19:47 prueba1.png

animanegra@T0m4t0:~$ ls -al prueba2.png
-rw-r--r-- 1 animanegra animanegra 919 2008-12-11 19:48 prueba2.png

:S

Si los modo indexados de mas de 256 colores (8 bits) tira de rgb deberia de ocupar lo mismo o mas, si ademas debe de guardar la informacion de paleta. :S

Creo que o te entendido mal o me estoy haciendo la picha un lio. XD O las dos cosas a la vez
"PoCoYo es dios!!"

SplinterGU

La wiki dice...

"With indexed color images, the palette is always stored in RGB at a depth of 8 bits per channel (24 bits per palette entry). The palette must not have more entries than the image bitdepth allows for but it may have fewer (so if an image for example only uses 90 colors there is no need to have palette entries for all 256).

Indexed color PNGs are allowed to have 1, 2, 4 or 8 bits per pixel by the standard; greyscale images with no alpha channel allow for 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bit depth per channel of either 8 or 16. The combinations this allows are given in the table above. The standard requires that decoders can read all supported color formats but many image editors can only produce a small subset of them."

Dice:

Indexed color PNGs = 1, 2, 4 u 8 bits por pixel...
Indexed color PNGs = si una imagen usa 90 colores no tiene necesidad de tener la PALETA COMPLETA de "256" entradas.

Te estas olvidando que con index guardas 1 byte por pixel, y este byte es el indice de la paleta (parcial, no necesariamente los 256 colores) y en RGB van 4 bytes por pixel.

Y tambien dice otras tantas cosas mas...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

animanegra

Acabo de fijarme lo que es. ^^ que le pongo usa 1024 colores... pero nanai :D Pero es guai ver como funcionan los programas... bueno y los usuarios. Joder, hay que reportarles para que te salte un error y no te lo guarde y confies que tienes una paleta de mas colores :P
"PoCoYo es dios!!"

SplinterGU

#18
Por favor lean en el wiki la informacion de la tablita "PNG color options,[6] cell values are total bits per pixel for that combination"... donde dice que soporta cada tipo de formato...

index solo es para graficos de 8 bits o menos...

y los demas (por lo menos eso veo en el codigo de carga de los png) son de 32 bits... se descarte o no bits al leer para adaptarlo al modo requerido... repitiendo, nunca el codigo de carga de png de fenix/bennu cargo pngs que tengan fisicamente tamaño de 16 bits por pixel, siempre manipulo datos de 32 (salvo palette index, que son de 8 bits o menos)... convirtiendolos en cada caso... es lo que la libpng retorna, y por ende debo suponer que esos datos no los inventa la libpng...

Lo que si es cierto es que al guardar los png, se le dice que son de 8 bits por canal... cuando estos son de 16 o 32, pero se les dice que son de paletas de 8 bits (y palette index) cuando son de 8 bits los graficos...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

SplinterGU

una cosa es la informacion del header del png y otra el contenido...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Prg

mmm, quizá mi comentario está fuera de linea (como la mayoría), sin embargo considero que para un juego, que es lo que hacemos, exportar en 8, 16 o 32 bits no es muy importante, si se van a editar fpgs la cosa cambia, por las reglas (eso de no mezclar profundiades), sin embargo si en algún juego decean que el jugador modifique su protagonista o algo así, y por eso necesitan salvar los pngs y cargarlos, creo que no debe haber problemas, pues no es necesario agregarlos a un fpg, con un array con sus códigos vasta. :)

Y si se exportan en 32 y no en 16 bits, pero bennu los puede cargar entonces no hay problema con esto.

Bueno, es mi opinión, quizá no estoy pensando en posibilidades grandes, pero pues para lo que hacemos (repito videojuegos), no es muy necesario todo esto. :)
en humos puedes mover la camara con los cursores. es necesario para los niveles a partir del dos :)

DCelso

#21
Con lo que he leído, corroboro que nadie ha probado mi ejemplo en donde se ven echos no conjeturas.   ;)
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

SplinterGU

si tu ejemplo hace algo fuera de la especificacion png entonces esta haciendo algo mal...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

SplinterGU

Acabo de ver tu ejemplo, haberlo visto antes y nos ahorrabamos toda esta charla...

El error no esta en bennu sino en la filosofia de tu ejemplo... El png que se guarde no va a depender del modo de video, sino que va a depender del fuente, en tu caso del fpg... si tu fpg es de 16 o 32 bits, nunca en tu vida vas a guardar un mapa de 8 bits...

aca te pongo un ejemplo clarito...


import "mod_video";
import "mod_map";
import "mod_say";

private
g;
begin
set_mode(640,480,16);
g = load_png("sample.png");
save_png(0,g,"sample-out.png");
end


Resumen:
PNG leido = 8 bits
PNG guardado = 8 bits
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

DCelso

Ok, muchas gracias, aclarado, hablando se endiende la gente. Aunque yo me refería al ejemplo último subido a megaupload donde con GIMP creo una imagen de dos colores, guardo, pongo tres vuelvo a guardar, pongo cuatro, ...., pongo 10, ... paso a RGB, y finalmente a RGBA.
http://www.megaupload.com/es/?d=U2E4CIGX
Todas las pruebas dan pngs distintos. Curiosamente los visores de pngs dicen que son imágenes de 32 bits de profundidad de color, pero yo he hecho un programilla en c usando libpng1.2 en el que extraigo la información de cabecera del png y muestro lo que realmente se encuentra en el png y que verdaderamente coincide con la realidad cuando lo abres con el GIMP. Mas o menos guarda relación con lo que comentas, no contradice lo que viene en la wiki.
Como resultado se aprecia que en GIMP imágenes indexadas sólo son permitidas de 1,2,4,8 bits por pixel.  Después ya se pasa a RGB de 24 bits y por último al añadir el canal alfa se pasa a 32 bits.
Vuelvo a repetir que todos estos formatos se pueden guardar en un png y que son pngs distintos al que extrayendo la cabecera correctamente se puede acceder a dicha información.
Se puede ver que 16bits de densidad por pixel no los crea GIMP, es lo que siempre se ha dicho de que 5-6-5 para RGB no es muy cómodo.
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

SplinterGU

yo probe tu ultimo ejemplo, en 2do que pusiste... no vi otro...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

SplinterGU

por lo que yo veo en el codigo de bennu, los 16 se arman en memoria a partir de uno de 32 en archivo, de 32 bits que no tiene alpha...
los de menor profundidad que 8 bits, bennu los graba como 8 bits...
y los de 32 o 16 bits depende del grafico, pero realmente son todos 32 bits (RGB)...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Prg

#27
QuoteCon lo que he leído, corroboro que nadie ha probado mi ejemplo en donde se ven echos no conjeturas.   Wink
en realidad yo sí lo había mirado :)
[code language="bennu"]
---------------
info_ptr->pixel_depth :1
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :2
-------------------------------------------------------
info_ptr->pixel_depth :2
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :3
-------------------------------------------------------
info_ptr->pixel_depth :2
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :4
-------------------------------------------------------
info_ptr->pixel_depth :4
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :5
-------------------------------------------------------
info_ptr->pixel_depth :4
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :6
-------------------------------------------------------
info_ptr->pixel_depth :4
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :15
-------------------------------------------------------
info_ptr->pixel_depth :8
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :20
-------------------------------------------------------
info_ptr->pixel_depth :24
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :3
info_ptr->num_palette :0
-------------------------------------------------------
info_ptr->pixel_depth :32
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :4
info_ptr->num_palette :0
------------------------------------------------------- [/code]

sale esto
en humos puedes mover la camara con los cursores. es necesario para los niveles a partir del dos :)

DCelso

No se, no te estoy contradiciendo, supongo mas bien que son problemas de conceptos, ya que a medida que se va profundizando en el tema se va complicando más la cosa.
Es que si ya nos ponemos a hablar de densidad de bits por canal la liamos (o lo aclaramos).
Este enlace aclara un poco la idea
http://luciaalvarezplastica.googlepages.com/introducirimágenes

Si hablamos de color verdadero de pixel:
Actualmente lo más utilizado es 8bits por canal dando posibilidad de valores desde 0 hasta 255.
*una imagen a un canal es la típica imagen de escala de grises desde el 0-negro hasta el 255 blanco. Esto es 8 bits por pixel.
*una imagen a dos canales es una imagen con un canal gris y un canal alfa que representa la opacidad. Esto es 16 bits por pixel. (no podemos confundirlas con las pseudo RGB 5-6-5 que maneja fenix/bennu)
*una imagen a tres canales es la típica RGB, canal red, canal green, canal blue. Esto son 24 bits por pixel.
*una imagen a cuatro canales es la típica RGBA, canal red , canal green, canal blue , canal alfa. Esto son 32 bits de color.

Luego se complica si usamos 16bits por canal, actualmente algunas cámaras llevan un RGB en este formato por lo que daría 48 bits por pixel.

Si hablamos de color indexado complicamos más el tema porque es tener hasta un maximo de 256 colores en cualquiera de los formatos anteriores mencionados formando una paleta de colores. Y después un array de información de color de 8 bits por pixel, es decir que cada pixel se representará con un número del 0 al 255 que a su vez indica una posición dentro de la paleta de colores, siendo imposible dibujar un pixel con un color distinto a los 256 permitidos en la palate.

Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

DCelso

Ok prg, veo que lo viste,perdona entonces. Si que lo habeis mirado algunos :)
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/