Formato De Texturas

[lord_taran]

 Esto... yo no sé mucho del tema, pero según la Wikipedia PNG si que permite canal Alfa... En inglés es más amplio, pero no lo he leido entero:
[...]greyscale and alpha (level of transparency for each pixel)
¿Eso es, no?

[[Vil]]

 Si no me equivoco, a lo que se refería Pogacha con su aclaración, era que TGA tiene posibilidad de otro canal, y que lo usas como quieres, pa transparencia, alturas, especular... da =, solo "posee" esa informacióny la usas pa lo que quieres (normalmente transparencia)
Luego PNG tiene otro canal, pero se usa solo para la transparencia.

Pero pienso yo... si el PNG tiene ese canal ahí... no puede cargarse sin tener en cuenta la transparencia, y usarlo como mapa de alturas? (por ejemplo). No lo necesito... pero ya es por curiosidad.

[sés]

 

To store this matte information, the concept of an alpha channel was introduced by A.R.Smith in the late 1970s, and fully developed in the 1984 paper Compositing Digital Images, by Thomas Porter and Tom Duff. In a 2D image element which stores a color for each pixel, an additional value is stored in the alpha channel containing a value between 0 and 1. A value of 0 means that the pixel does not have any coverage information; i.e. there was no color contribution from any geometry because the geometry did not overlap this pixel. A value of 1 means that the pixel is fully opaque because the geometry completely overlapped the pixel.

PNG Alpha

Que TGA tenga la posibilidad de un canal genérico me parece estupendo, pero hablamos de canal alpha y PNG sí tiene. Además, tú puedes añadir los CHUNKs que te apetezcan.

[Xam]

 

En realidad para texturas se deberia usar el DDS el cual tiene sus librerias para cargar y todo, así que es una cuestion de gusto, yo que soy usuario de OpenGL me gustaria un formato multicapa comprimido estandar con capacidad de mimmapping y cubemaps como el dds, aparte de guardar con compresion de textura compatible con la de placa de video ... en cualquier momento saco mi formato el .pgf = "pogacha grafic format"

Yo también soy usuario de OpenGl y he estado trabajando en un formato con todo lo que dices (soporte para mipmaps, para cubemaps, texturas comprimidas S3TC, ...). Una especie de .dds pero más genérico. Sólo me queda comprimir los datos de las texturas con zlib para que el formato quede redondo. Además tengo una utilidad (parecida al DxTex.exe que viene con el SDK del DirectX) que te permite convertir archivos de imagen .bmp, .tga, .jpg y .png a este formato.

En referencia al tema del hilo. Nada que no se haya comentado ya. Los archivos .png soportan un canal alpha para transparencias mientras que los .tga soportan un canal extra que se puede utilizar para muchas cosas (un uso sería para transparencias).

[ajmendoza]

 Como apunte todos los trabajos que he entregado hasta ahora me los han pedido en formato .tga (y uno en .dds para no mentir). Luego desconozco, supongo que si, si utilizarán algún metodo de compresión propio, pero es asín.

Un saludor

[Pogacha]

En realidad para texturas se deberia usar el DDS el cual tiene sus librerias para cargar y todo, así que es una cuestion de gusto, yo que soy usuario de OpenGL me gustaria un formato multicapa comprimido estandar con capacidad de mimmapping y cubemaps como el dds, aparte de guardar con compresion de textura compatible con la de placa de video ... en cualquier momento saco mi formato el .pgf = "pogacha grafic format"

Yo también soy usuario de OpenGl y he estado trabajando en un formato con todo lo que dices (soporte para mipmaps, para cubemaps, texturas comprimidas S3TC, ...). Una especie de .dds pero más genérico. Sólo me queda comprimir los datos de las texturas con zlib para que el formato quede redondo. Además tengo una utilidad (parecida al DxTex.exe que viene con el SDK del DirectX) que te permite convertir archivos de imagen .bmp, .tga, .jpg y .png a este formato.

En referencia al tema del hilo. Nada que no se haya comentado ya. Los archivos .png soportan un canal alpha para transparencias mientras que los .tga soportan un canal extra que se puede utilizar para muchas cosas (un uso sería para transparencias).

(uoh)
Se puede saber mas sobre el tema ?
Piensas hacerlo publico ?
Me parece de lo mas interesante.

Saludos.

[Xam]

 

En realidad para texturas se deberia usar el DDS el cual tiene sus librerias para cargar y todo, así que es una cuestion de gusto, yo que soy usuario de OpenGL me gustaria un formato multicapa comprimido estandar con capacidad de mimmapping y cubemaps como el dds, aparte de guardar con compresion de textura compatible con la de placa de video ... en cualquier momento saco mi formato el .pgf = "pogacha grafic format"

Yo también soy usuario de OpenGl y he estado trabajando en un formato con todo lo que dices (soporte para mipmaps, para cubemaps, texturas comprimidas S3TC, ...). Una especie de .dds pero más genérico. Sólo me queda comprimir los datos de las texturas con zlib para que el formato quede redondo. Además tengo una utilidad (parecida al DxTex.exe que viene con el SDK del DirectX) que te permite convertir archivos de imagen .bmp, .tga, .jpg y .png a este formato.

En referencia al tema del hilo. Nada que no se haya comentado ya. Los archivos .png soportan un canal alpha para transparencias mientras que los .tga soportan un canal extra que se puede utilizar para muchas cosas (un uso sería para transparencias).

(uoh)
Se puede saber mas sobre el tema ?
Piensas hacerlo publico ?
Me parece de lo mas interesante.

Saludos.

Claro. Siempre se agradece que alguien muestre interés por el trabajo de uno.

La idea es hacer un formato que facilite, lo máximo posible, la gestión de las texturas en un motor gráfico. Algo como el .dds que utiliza directX pero más genérico (para que pueda ser utilizado por cualquier API gráfica), más potente y más versátil.

Tengo una clase (que representa el concepto de archivo de imagen) que puede ser inicializada a partir de ficheros .bmp, .tga, .png y .jpg. Esta clase almacena la informacion que interesa sobre los ficheros de imagen y puede ser salvada/cargada a partir de un formato binario propio con extensión .xei ( Xam´s engine image file). Sobre esa clase he construido una nueva clase para gestionar el concepto de mapa de textura (añadiendo algunos campos para almacenar informacion propia de mapas de texturas). Esta clase ofrece las siguiente posibilidades:

  * Permite trabajar con ficheros de imagen con 1, 3 o 4 componentes por pixel. Con un tipo de dato 'unsigned int8' para cada componente. Y
     una de siguientes codificaciones de pixels: RGB(A), BGR(A) o escala de grises. Las imagenes con paleta se convierten a RGB(A) o BGR(A).
  * Gestión de mapas de textura sencillos, cubemaps y niveles de detalle de los mismos.
  * Algoritmos avanzados en el tratamiento de imágenes. Permitiendo la aplicación de filtros especializados (Mitchell & Netravalli, Sinc con
     ventana Kaiser, ...) para el cálculo de los niveles de detalle (mipmaps). Obteniendo resultados muy superiores a los obtenidos con el
     típico filtro 2x2 utilizado comúnmente para estas tareas.
  * Cálculo de niveles de detalle con precisión float32 en el espacio lineal de la luz.
  * Soporte para mapas, cubemaps y niveles de detalle de los mismos comprimidos en formatos S3TC (DTX1, DTX3, DTX5).
  * Conversión de mapas de alturas en mapas de normales (mediante distintas técnicas). Utilización de algoritmos particulares (distintos a los
     utilizados para los mapas de color) para el cálculo de los niveles de detalle para los mapas de normales teniendo en cuenta la naturaleza de
     los mismos.
  * Soporte para el salvado de todos los niveles de detalle que forman un mapa o cubemap en ficheros de imagen (.xei, .bmp, .tga, .jpg o .png)
     independientes.
  * Soporte de cargado/salvado a partir de un formato binario propio con extensión .xem (Xam´s engine map). Permitiendo la carga de un mapa
     de textura o cubemap a partir de un nivel de detalle concreto para facilitar el soporte para distintas calidades de texturas dependiendo de la
     memoria disponible.
  * Aplicación con interfaz de usuario para facilitar la creación de distintos tipos de mapas a partir de ficheros de imagen .bmp, .tga, .jpg y .png.

Todavía estoy trabajando en alguna cosilla más. Como lo de la compresión de los datos de los mapas mediante zlib. Pero ya se puede ir tirando con lo que hay. Si aún te queda alguna duda no te quedes con las ganas y pregunta.

Sobre lo de liberarlo. Pues todavía no lo sé. Si la gente muestra interés puede que me anime. Lo cierto es que el proceso no debería ser muy costoso. Está programado bajo ANSI C ++ (o por lo menos eso he intentado) como una librería. El funcionamiento de las clases es bastante intuitivo. Además,  el código está perfectamente documentado (cada función con su cabecera, cada constante con una descripción) de forma compatible con Doxygen.  De modo que se le podría sacar partido de forma rápida sin muchas complicaciones. Yo lo utilizo bajo windows pero seguramente no habría mucho problema en portarlo a Linux. Utilizo la librería 'libpng' para la lectura de los ficheros .png (por lo tanto también utilizo 'zlib') y la librería 'jpegLib' para la lectura de ficheros .jpg. El resto es todo código mío.

[Pogacha]

  (ole)  (ole)  (ole) Eso esta buenisimo!!!
Es un proyecto de lo mas interesante.
Cuando decia liberarlo, no me referia al codigo sino al uso ... tienes una web en donde descargarlo o algo así?
Me gustaria mirarlo, si necesitas alguna ayuda con algun codigo me gustaria contribuir (en lo que mi escaso tiempo me permita)
Mantenme informados.
Saludos.

[_XUTI_H_]

 

...

Tengo una clase (que representa el concepto de archivo de imagen) que puede ser inicializada a partir de ficheros .bmp, .tga, .png y .jpg. Esta clase almacena la informacion que interesa sobre los ficheros de imagen y puede ser salvada/cargada a partir de un formato binario propio con extensión
...

Brutal ...

Aunque no sé muy bien que es lo de los mipmaps esos ... (( podría tener algo que ver con el escalado de texturas??? )) ...

Y lo de poder tener la textura comprimida en VRAM moolaaaa.

Salu2

[[Vil]]

 El mipmap es que la textura se vea a menos resolución a partir de una distancia tal de la camara, evita un efecto de pixelado mu feo. Supongo que lo que hace el formato es fuargar diferentes versiones de la textura a menos resolución

[Xam]

 

(ole)  (ole)  (ole) Eso esta buenisimo!!!
Es un proyecto de lo mas interesante.
Cuando decia liberarlo, no me referia al codigo sino al uso ... tienes una web en donde descargarlo o algo así?
Me gustaria mirarlo, si necesitas alguna ayuda con algun codigo me gustaria contribuir (en lo que mi escaso tiempo me permita)
Mantenme informados.
Saludos.

Perdona Pogacha por tardar tanto en contestar. He tenido una semanita bastante movida.

Gracias de nuevo por mostrar tanto interés y ofrecerte como colaborador. Es dificil encontrar gente que aprecie este tipo de proyectos.

Sobre lo de hacerlo público. Ahora mismo no tengo acceso a ninguna página web ni a ningún servidor. Pero supongo que si alguien más se interesa no habría mucho problema en encontrar algún sevidor donde subir el .h y la librería para poder probarlo. Incluso podría subir el código fuente una vez se acabe el proyecto.  Además, la librería para leer ficheros de imagen (sin tener en cuenta sus propiedades como mapas de textura) también podría ser interesante para la gente que trabaja sobre 2d.

De cualquier modo, supongo que te lo podría mandar a una dirección de correo. Si quieres podemos hablar sobre esto y sobre la colaboración por privados.

Aunque no sé muy bien que es lo de los mipmaps esos ... (( podría tener algo que ver con el escalado de texturas??? )) ...

Más o menos Vil ha comentado por donde van los tiros. De todas formas, voy a explicar con un poco más en detalle el funcionamiento y el porqué de los mipmaps. Para el que no le interese el tema, este es un buen momento para dejar de leer.

Para filtrados de minificación de texturas más complejos que el bilineal se utilizan versiones reducidas de la misma textura (éstos son los mipmaps o niveles de detalle). Esto tiene sentido por varios motivos:

* Si un triángulo se encuentra alejado respecto de la cámara. El número de pixels (superficie) de éste será menor que si se encuetra cerca de la misma (proyección perspectiva). Si junto con la textura asociada al triángulo se proporcionan versiones reducidas de la misma, dependiendo de la distancia del triángulo a la cámara se pueden utilizar estas versiones reducidas de la textura para renderizar. Con el consiguiente ahorro en el ancho de banda. Puesto que los niveles de detalle ocupan bastante menos que la textura original (las dimensiones de cada nivel de detalle respecto al nivel de detalle superior son la mitad (en el ancho y en el alto). Con lo que cada nivel de detalle ocupa la cuarta parte respecto a su nivel de detalle inmediatamente superior).

* Si se utiliza una textura (sin mipmaps) para renderizar un triángulo independientemente de dónde se encuentre con respecto a la cámara. (Se asume que se trata de una textura con suficiente detalle (tamaño) para el momento en el que el triángulo se vea en un primer plano y utilizando un filtro de minificación bilineal para la misma). Cuando el triángulo se encuentre suficientemente alejado de la cámara y la cámara se encuentre en movimiento se podrá apreciar un "baile de pixels" (cambios de color bruscos) en el renderizado del triángulo. Esto se debe a que el filtro no dispone de información suficiente (entre otras cosas) para aproximar correctamente, en frames sucesivos, los texels que se corresponden con esos pixels alejados de la cámara. Este efecto siempre existe. Evidentemente, dependiendo del "contenido" de la textura se ve más o menos acentuado.

En el tema de filtrados de textura, además de la posición de los triángulos respecto a la cámara, también tiene bastante importancia la orientación de los mismos respecto a la cámara. Pero creo que esto ya se escapa algo del tema.

Espero que la explicación haya ayudado a alguien.