Smart Fpg Editor

Started by darío, January 03, 2009, 12:27:18 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

darío

No es un error del programa, es el funcionamiento normal por lo siguiente.

Smart Fpg Editor entiende las transparencias de la siguiente forma:

En 8bpp --> El indice de color 0
En 16bpp --> El negro
En 32bpp --> Cualquier color con la componente alpha distinta de 255

Cuando tu haces una copia de un gráfico con photoshop, la imagen que se crea es de 32 bpp (en concreto, un DIB de 32bpp y que además, no tiene transparencia -si tu imagen tiene canal alpha, se creará en memoria un DIB de 32bpp acoplado con el fondo, que en general es blanco-) y esto es independiente de si en photoshop trabajas con una imagen de un tipo o de otra (el DIB creado en el buffer del copy&paste es el mismo).

El funcionamiento de Smart Fpg Editor cuando hay que hacer conversiones de color:

Para 16bpp, una imagen que no tenga una profundidad exacta de 16bpp (pj un png de 32) para que una parte sea transparente, tiene que tener su componente alpha < 128 (>=50% de transparencia).

En 32bpp, el negro nunca se interpretará como transparente.

Conclusión: Una imagen copiada de photoshop u otro programa a SFPGE nunca hará transparente el negro ya que los DIBs siempre serán de 32bpps.

El funcionamiento de smart fpg editor es análogo a lo que haría bennu.

Si tu cargas un PNG (que no hay de 16), las partes que se interpretan como transparentes son únicamente aquellas que tienen una transparencia superior al 50%. Prueba a guardar tu imagen negra como un PNG de 32bpp y a cargarlo con Bennu y lo verás.

Podría poner una opción al añadir un gráfico que "convirtiese" el negro a transparente, Pero esto solo tiene sentido en "16bpp".

Así que el funcionamiento de Smart Fpg Editor creo que es correcto. Otra cosa es que de cara al trabajo, el copy&paste no sea muy útil si no se pueden hacer ciertas operaciones y para eso la única forma es añadir opciones a la hora de agregar un gráfico.

Pensaré qué hacer, pero no puedo decir que sea un "bug" de SFPGE, funciona como quise que funcionase.

Para gráficos transparentes de momento la única forma es trabajar con transparencias y un formato que lo admita, o con imágenes en 16bpp (por ejemplo tiff o bmps de 16bpp, donde el negro será interpretado como transparente).

Un saludo,
darío
My sites:
Smart Fpg Editor - Painless FPG Edition for Bennu and PixTudio
fenixlib - .NET support for manipulating PixTudio, Bennu and Div graphic formats

Fede

Ejem...

Gracias por la explicación pero apenas he pillado nada.

No entiendo de canales alpha porque todavía no me he metido a hacer transparencias en ningún gráfico.

Sólo sé que el (0,0,0) es el color que bennu hará transparente.

Ahora bien, si tu programa por alguna conversión me transforma ese color en (0,0,8) no lo comprendo.

Si PhotoShop no me lo hace, ¿por qué lo hace el tuyo?

El color (0,0,0) debería de ser (0,0,0) independientemente de la profundidad de bits que tenga la imagen.

Otro ejemplo.

Abro el paint, pinto un cuadrado negro (0,0,0), lo pego en el fpg de 16 bis. Lo vuelvo a leer desde el fpg y se ha convertido en (0,0,15).

Saludos y de verdad, gracias por el exfuerzo.


Si quieres ser sabio, aprende a interrogar razonablemente, a escuchar con atención, a responder serenamente y a callar cuando no tengas nada que decir.

darío

Prueba lo siguiente:

1 - Guarda un png totalmente negro de 32bpp
2 - Haz un programa en bennu que setee el modo a 16 y carga ese archivo png con load_png en un graph

Entonces verás que el (0,0,0) ya no es (0,0,0).

De todos modos revisaré lo que dices de que se convierta a 0,0,8 o 0,0,15 (eso si que me sorprende un poco) en función de donde pegues.

Este finde seguro que tengo un rato para revisarlo.

Un saludo y gracias a tí.
My sites:
Smart Fpg Editor - Painless FPG Edition for Bennu and PixTudio
fenixlib - .NET support for manipulating PixTudio, Bennu and Div graphic formats

Drumpi

Lo que quiere decir es que el formato de una imagen cualquiera se guarda en formato de 32 colores. Si quieres guardarla en un FPG de 16, el color transparente sólo atiende al canal alpha ¿que qué es el canal alpha?

Como sabemos, cada pixel tiene tres componentes de color, RGB, que se definen por un valor entre 0 y 255 (usar más es tontería, el ojo humano no es capaz de captarlo), lo que nos dan 3 valores de 8 bits, o sea, 24 bits por pixel. Como la memoria de los ordenadores se alinean en potencias de 2, lo ideal es que cada pixel se represente mediante 8bits (paleta de 256 colores), 16 bits o 32 bits.
Con 24bits nos sobran 8 ¿qué hacemos con ellos? los usamos para indicar cómo de transparente es el pixel (0 es completamente transparente y 255 es opaco). Esto nos da una imágen de tipo RGBA (Red, Green, Blue, Alpha) en lugar de RGB (Red, Green, Blue). De ahí el canal alpha, igual que existe el canal verde, el azul y el rojo.


Hasta ahora, todas las imágenes se guardan en 8bits, 24bits y 32bits:
-8bits está casi obsoleto, salvo para el formato GIF.
-32bits es el formato normal, ya que casi todos los formatos actuales soportan transparencias.
-24bits es menos común, pero se usa (ejemplo claro, el BMP de toda la vida, antes de la aberración post Wxp).

Conclusión, usar el canal alpha para definir el color transparente, y si no existe, usar el negro puro. En este caso, Bennu es aun más restrictivo, porque en imágenes de 32bits, el color transparente es el RGBA=(0,0,0,0).
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Fede

Gracias Drumpi. Ahora más o menos lo cojo.

Pero sigo sin entender que tipo de conversión se le aplica para convertir un 0,0,0 en un 0,0,8.

Si en 16 bits no lleva información del alfa y el 0,0,0 es tan importante en bennu, ¿por qué no se hace una excepción con ese color?

Me refiero sólo en 16 bits. En otro ya se supone que sería 0,0,0,x y habría que respetarlo.

Si quieres ser sabio, aprende a interrogar razonablemente, a escuchar con atención, a responder serenamente y a callar cuando no tengas nada que decir.

Drumpi

Porque no hay formatos estandar que soporten 16bits, no al menos el (5,6,5) de Bennu, por lo general se usa el (5,5,5) (es el número de bits de cada componente).

Se ha tomado como patrón que, si el formato que se vaya a convertir no soporta canal alpha, sea el color 0 el transparente (es el caso del BMP), pero si lo acepta, debe usarse el canal alpha para definirlo (como pasa con PNG) y de no hacerlo, se supone que se quería poner un color negro sin transparencias, y se cambia por el color 1=(0,0,8) (se usa el 8 porque en lugar de usar 8 bits para la componente azul, en modo 16bits se usan 5bits, por lo que hay que dividir entre 8 dicho valor para hacer la conversión).
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Fede

Bueno, más o menos lo he cogido. Gracias Drumpi.

Una solución sencilla que se me ocurre, es tener una opción en la configuación del programa para forzar un tipo de comportamiento u otro. Vamos, si es que se puede.

Ya que trabajamos con Bennu, supongo que el programa debería adecuarse a las necesidades del lenguaje y no a la del 'mundo real'.

A ver que dice Dario. Si esto tiene solución, o a aguantarse. :D
Si quieres ser sabio, aprende a interrogar razonablemente, a escuchar con atención, a responder serenamente y a callar cuando no tengas nada que decir.

darío

Hola,

Gracias Drumpi por la explicación... la verdad es que mis respuestas han sido escuetas pero es por la falta de tiempo.

Fede, precisamente por los motivos que comenta drumpi, esta es la forma de trabajar con gráficos cuando se crea un FPG de 16bpp en SFPG.

1 - Si añades un gráfico que tenga paleta, el color 0 se puede usar como color de transparencia (también se puede omitir este comportamiento con la lista de opciones que sale en la ventana "Añadir gráfico")

2 - Si añades un gráfico de 16bpp, por ejemplo un BPM, un TIFF u otro formato que soporte esta profundidad (puedes probarlo con el paint), entonces el NEGRO SÍ se interpreta como color transparente (también se puede omitir este comportamiento)

3 - Si añades un gráfico de más profundidad, entonces NO se asume que el negro sea el transparente, sino que aquellos pixeles que sean un 50% o más transparente serán los que se consideren transparentes (dentro del FPG tendrán el color 0,0,0).  El negro puro se transforma a otro color.

Creemé, esto lo estuve pensando mucho y me parece que es la manera más correcta. Como el Copy&Paste genera gráficos de 24bpp, se está en la situación 3 y es por eso que el negro de la imagen se transforma a "otro color" cercano al negro.

Ahora bien, obviamente a mi lo que me interesa es ofrecer soluciones y de hecho en este caso es bastante sencilla: Para el caso 3 añadir una opción en la que considere el negro como color transparente (y que salga en el listado de opciones que hay cuando se añade un gráfico).

Obviamente ha de ser una opción porque si no, el que quiera hacer un gráfico negro tendrá que tener presente todo el rato que tendría que usar el 0,0,8 y esto no es para nada intuitivo.

Esto es sencillo de hacer y creo que cubrirá tus necesidades (y creo que es una buena mejora). Lo incluiré para la siguiente release.

En realidad, yo solo quise exponer al principio que no se trataba de un error del programa sino más bien de la forma en la que ha sido diseñado, pero obviamente debo tener en cuenta el uso que hacéis los usuarios y ofrecer soluciones a los problemas porque al fin y al cabo lo que a mi me gusta es que haya gente que le sirva el programa, y eso es lo que me anima a continuarlo.

Bueno pues eso, os mantengo al tanto.

Un saludo y espero que se haya aclarado más la cosa.
My sites:
Smart Fpg Editor - Painless FPG Edition for Bennu and PixTudio
fenixlib - .NET support for manipulating PixTudio, Bennu and Div graphic formats

darío

Por cierto Drumpi, te "karmeo" por ahorrame a mì la explicación ;)
My sites:
Smart Fpg Editor - Painless FPG Edition for Bennu and PixTudio
fenixlib - .NET support for manipulating PixTudio, Bennu and Div graphic formats

Fede

No te beso porque no llego.   :-*

¡Otro karma!
Si quieres ser sabio, aprende a interrogar razonablemente, a escuchar con atención, a responder serenamente y a callar cuando no tengas nada que decir.

Drumpi

Fede, porque te conozco, porque si no, con tanto beso, voy a empezar a pensar mal (y creo que también tengo que meter a Futu en el mismo saco :D:D:D).

Lo cierto es que trabajar con FPGs, en este aspecto, muchas veces es muy pesado, y acabas por recurrir a otros programas (DIV, código propio...). Ejemplo claro fue la de problemas que tuvimos en el último juego de Locura Andaluza, aun se ven muchos gráficos con transparencias donde debía ir el color negro.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)


FreeYourMind

Buenas, estaba subiendo graficos a un fpg de 32 bits, iba creo por el 444 y la aplicación tuvo un crash.

El problema es que ahora si vuelvo a abrir el smart editor tengo siempre el crash al abrirlo...
Seguramente sólo se resuelva reiniciando. Por otro lado ahora mi miedo es que el fpg se haya dañao.


FreeYourMind

con cerrar sesión se ha arreglao, el fpg esta bueno

KeoH