Empiezo a exportar de todos los .PSD que tengo, y me aparece la duda... JPG, TGA, XXX...?
Olvidando el aspecto de que guarden canal alpha (creo que solo TGA y PNG), cual es mejor? cual suele usarse?
JPG tengo las diferentes compresiones (que incluso en minima compresion ocupa menos que el TGA con compresión). Pierde siempre calidad el JPG? aumenta mucho los tiempos de carga?
TGA, la posibilidad de meterle compresión, que tipo de compresión es? pierde calidad?
Y no se de otros formatos. De momento usare TGA siempre q necesite canal alpha, pero para el resto... estoy con la duda
Se que podría documentarme sobre formatos (lo he hecho alguna vez, y olvidado lo aprendido luego...) pero sobre todo por saber que suele hacerse (me fio más de los experimentados que lo que yo pueda concluir)
Gracias
JPG siempre pierde calidad, incluso al 100% de calidad, por el proceso matemático aplicado (cuantización). TGA y PNG no pierden calidad al comprimir. La mayoria de las veces JPG comprime muchisimo más a menos que sea una imagen muy lisa con muchos pixeles del mismo color consecutivos.
Un fichero comprimido tarda más en procesarse una vez en memoria (hay que descomprimirlo) pero un fichero sin comprimir son más datos a leer del disco, y eso si que es una tarea lenta. Imaginate leer 1 mega del disco en lugar de 40ks...
TGA: Compresión RLE pero casi todo el mundo los usa sin comprimir. RLE = sustituir tiras de pixels del mismo color, por un número que indica el color y otro que indica cuantos pixeles iguales le siguen. No hay pérdida de calidad, pero la mayoría de las imágenes "realistas" engordan en lugar de comprimirse.
Yo no sé demasiado del tema, pero para usar TGA usa mejor PNG que soporta alpha igualmente y además tiene una buena compresión :).
Yo sigo sin entender la velocidad de respuesta de este foro...
Creo que me decanto por PNG, que creo q es libre y TGA no. Y pa no usar JPG y PNG, me quedo con PNG que comprime algo menos pero sin perdidas.
A no ser que llegue un grafo que me tire piedras rajando del PNG
Muchas gracias
Lo cojonudo de TGA es que es simplísimo de cargar y guardar. Yo uso TGA para guardar los screenshots de la aplicación o cuando genero una textura al vuelo y quiero verla.
la compresion no solo no funciona en la memoria de la tarjeta sino que ademas debe descomprimirse antes de cargarse, los unicos archivos que fucnionan comprimidos en memoria son lo dds.
el tga es el unico que realmente usa el canal alpha, el png no usa canal alpha es la trasparencia como la del gif y por tanto mas coñazo de guardar.
el TGA es facil de implementar, asi que suele ser el elegido cuando se necesita un canal alpha. PNG es una opcion fantastica porque sirve para cualquier tipo de imagen, mantiene un ratio bastante bueno, incluso aunque hagas un empaquetador de ficheros (con zlib o lo que sea), png comprime mejor que un tga pasado por zip (y eso que libpng usa zlib).
Y aunque solo sea por no usar formatos propietarios como jpeg y tga, merece la pena.
Ademas me gusta las siglas :D
Evidentemente, una vez cargues en memoria de video, nadie te salva de los 512x512 de la textura.
yo tambien me decanto por el png ya que lo veo un estandar bastante bueno, aunque no es muy visto en ordenadores, para moviles es la joya numero 1
saludos
Yo suelo usar jpg si no lleva transparencias, y tga si las lleva. Un jpg con una compresión del 80-85% reduce muchísimo el espacio en disco sin perder demasiada calidad. También uso de algún que otro png, lo mejor es que pruebes y veas qué resultados son los que te gustan más.
Opiniones seguro que hay de todos los gustos.
Cita de: "er_willy"el tga es el unico que realmente usa el canal alpha, el png no usa canal alpha es la trasparencia como la del gif y por tanto mas coñazo de guardar.
:P Falso, PNG soporta perfectamente transparencia:
PNG Demo
recordar que esta demo no funciona en nuestro amigo IE (twist)
Cita de: "sés"Cita de: "er_willy"el tga es el unico que realmente usa el canal alpha, el png no usa canal alpha es la trasparencia como la del gif y por tanto mas coñazo de guardar.
:P Falso, PNG soporta perfectamente transparencia: PNG Demo
Lo que creo que dijo es que el png no tiene canal alpha lo cual es cierto, el png tiene transparencia, el canal alpha puede ser la altura u otra cosa, la transparencia es solo transparencia.
Y hablando de formatos, si usas la png lib el formato png es mas facil que el tga ... el unico problema es que el tga es el unico que conozco que tiene canal alpha (aparte del dds).
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"
El png es bastante practico para sprites y esas cosas, el canal alpha del tga sirve para cuando lo usas para otra cosa como el especular monocromatico o algo así sino te diria que uses el png que anda bastante bien, compresion sin perdidas y carga rapida.
Saludos.
Pues, despues de hacer pruebas, reafirmo mi decantación PNG, a espera del PGF de pogacha.
de una textura de 1024x1024 cartoon (no fotorealista)
2049 BMP
1142 TGA (con compresion)
238 PNG (con interlaced a NONE)
24 JPG (calidad 9/12 del pshop)
PNG tiene "transparecencia" q es lo que quiero, no voy a necesitar otro canal, ocupa bastante poco y a mi tambien me molan las siglas
No entiendo la diferencia entre canal alpha y transparencia. Tenía entendido que una imagen con transparencia simplemente era una matriz de RGBA, donde R es el canal rojo, G el verde, B el azul y A el alpha. Vamos, que canal alpha==transparencia.
Ahora leo que decís que no es así. ¿Me lo podéis explicar con más detalle o darme algún enlace donde lo explique pormenorizadamente?
Gracias.
Para mi un canal alpha es un valor que puede variar entre un rango de valores que determinará el nivel de trasparencia. Si es de 8 bits pues tendra de 0 a 255 niveles. si es de 1 bit pues será un simple "color key" opaco o trasparente.
Siento no poder dar una explicación pormenorizada, habrá que esperar a los expertos.
1 saludo.
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?
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.
CitarTo 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 AlphaQue 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.
Cita de: " Pogacha @ 03/09/05"
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).
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
Cita de: "Xam"Cita de: " Pogacha @ 03/09/05"
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.
Cita de: "Pogacha"Cita de: "Xam"Cita de: " Pogacha @ 03/09/05"
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.
(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.
Citar...
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
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
Cita de: "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.
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.
Citar
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.