erachude
Nub
Cakes 0
Posts: 29
|
|
« on: January 21, 2007, 12:43:56 PM » |
|
hi leileilol, in the "skinning md3 with blender" thread, on the subject of using pngs in openarena, you said... there's a PNG patch, but I wouldn't recommend using other image formats as that would break vanilla compatibility. i can understand that if openarena started using pngs it would break vanilla compatibility in the sense that the openarena content would no longer run on the original quake3 engine, but is that really something to worry about? as long as png support didn't stop quake3 mods running on openarena then everything's ok, isn't it? btw, do you have a link to this patch? i'd like to experiment with it.
|
|
|
Logged
|
|
|
|
erachude
Nub
Cakes 0
Posts: 29
|
|
« Reply #1 on: January 22, 2007, 06:31:44 AM » |
|
found it... https://bugzilla.icculus.org/show_bug.cgi?id=2718there's some interesting info further down the page. This patch adds support for PNG images to icculus.org/quake3. It doesn't need any external libraries. The PNG parser was written by myself so no libpng is needed. looks like it doesn't add any more dependencies. Converting old TGA or JPG textures to PNG :
Quake 3 tries to load the JPG image of the same name when it can't find the original TGA. I have expanded this mechanism and now it tries to load the PNG too. So you can convert all of your JPG and TGA textures to PNG images. Attention : Textures for MD3 models don't work anymore when converted to PNG. sounds pretty good except for the bit where it doesn't work with md3 models. ------- Comment #2 From Thilo Schulz 2006-05-31 21:12:02 [reply] -------
Nice work (though I didn't test it yet). I guess the earliest time of inclusion would be after ioq3 1.34 has been released. Of course, I don't have the final word about this.
------- Comment #3 From Zachary J. Slater 2006-05-31 21:13:01 [reply] -------
After 1.34, for sure.
so it looks like it will be part of the default ioquake3 engine at some point.
|
|
|
Logged
|
|
|
|
erachude
Nub
Cakes 0
Posts: 29
|
|
« Reply #2 on: January 22, 2007, 06:42:54 AM » |
|
hmmm, i had a look at the wikipedia page on PNGs and there was a section where it compared JPEGs and PNGs..... JPEG will produce a smaller file than PNG for photographic (and photo-like) images since it uses a lossy encoding method specifically designed for photographic image data. Using PNG instead of a high-quality JPEG for such images would result in a large increase in filesize (often 5-10 times) with negligible gain in quality.
PNG is a better choice than JPEG for storing images that contain text, line art, or other images with sharp transitions that do not transform well into the frequency domain. Where an image contains both sharp transitions and photographic parts a choice must be made between the large but sharp PNG and a small JPEG with artifacts around sharp transitions.
JPEG is a poor choice for storing images that require further editing as it suffers from generation loss, whereas lossless formats do not. This makes PNG useful for saving temporary photographs that require successive editing. When the photograph is ready to be distributed, it can then be saved as a JPEG, and this limits the information loss to just one generation. That said, PNG does not support Exif image data from sources such as digital cameras, which makes it problematic for use amongst amateur and especially professional photographers. TIFF does support it as a lossless format, but is much larger in file size for an equivalent image.
JPEG has historically been the format of choice for exporting images containing gradients, as it could handle the color depth much better than the GIF format. However, any compression by the JPEG would cause the gradient to become blurry, but a 24-bit PNG export of a gradient image often comes out identical to the source vector image, and at a small file size. As such, the PNG format is the optimal choice for exporting small, repeating gradients for web usage. the first line kind of kills the idea of using PNGs. it really doesn't sound like a good choice game graphics.
|
|
|
Logged
|
|
|
|
ratix
|
|
« Reply #3 on: January 22, 2007, 08:41:20 AM » |
|
hmmm, i had a look at the wikipedia page on PNGs and there was a section where it compared JPEGs and PNGs..... JPEG will produce a smaller file than PNG for photographic (and photo-like) images since it uses a lossy encoding method specifically designed for photographic image data. Using PNG instead of a high-quality JPEG for such images would result in a large increase in filesize (often 5-10 times) with negligible gain in quality.
PNG is a better choice than JPEG for storing images that contain text, line art, or other images with sharp transitions that do not transform well into the frequency domain. Where an image contains both sharp transitions and photographic parts a choice must be made between the large but sharp PNG and a small JPEG with artifacts around sharp transitions.
JPEG is a poor choice for storing images that require further editing as it suffers from generation loss, whereas lossless formats do not. This makes PNG useful for saving temporary photographs that require successive editing. When the photograph is ready to be distributed, it can then be saved as a JPEG, and this limits the information loss to just one generation. That said, PNG does not support Exif image data from sources such as digital cameras, which makes it problematic for use amongst amateur and especially professional photographers. TIFF does support it as a lossless format, but is much larger in file size for an equivalent image.
JPEG has historically been the format of choice for exporting images containing gradients, as it could handle the color depth much better than the GIF format. However, any compression by the JPEG would cause the gradient to become blurry, but a 24-bit PNG export of a gradient image often comes out identical to the source vector image, and at a small file size. As such, the PNG format is the optimal choice for exporting small, repeating gradients for web usage. the first line kind of kills the idea of using PNGs. it really doesn't sound like a good choice game graphics. It depends on the usage; As you read, PNGs are good for storing text and other graphics with sharp egdes and with full alpha transparency you can make some really nice effects, simple images (like text and full or few colour images) compresses to only a few kilobytes, while jpeg's lossy algorithm can manage to compress it with the same filesize as a photographic image. Uncompressed TGA-files (default) are usually much bigger in size than PNG.
|
|
|
Logged
|
|
|
|
erachude
Nub
Cakes 0
Posts: 29
|
|
« Reply #4 on: January 22, 2007, 12:58:34 PM » |
|
hi ratix, i'm guessing that JPEGs would be the way to go for the majority of game textures, but i suppose there would be a few cases where png might be useful. stuff like posters and logos would be perfect for PNGs.
|
|
|
Logged
|
|
|
|
dmn_clown
Posts a lot
Cakes 1
Posts: 1324
|
|
« Reply #5 on: January 22, 2007, 01:50:31 PM » |
|
Does that patch include support for 16-bit png or just 8-bit?
|
|
|
Logged
|
|
|
|
fromhell
|
|
« Reply #6 on: January 22, 2007, 02:05:12 PM » |
|
it'd be redundant because OA uses PK3s which is ZIP and can provide compression for TGAs. PNG doesn't have hot loading speeds either.
|
|
|
Logged
|
asking when OA3 will be done won't get OA3 done. Progress of OA3 currently occurs behind closed doors alone I do not provide technical support either.new code development on github
|
|
|
dmn_clown
Posts a lot
Cakes 1
Posts: 1324
|
|
« Reply #7 on: January 22, 2007, 09:41:21 PM » |
|
Yes, but there are 8-million more colors available in a 16-bit image which might translate to better looking textures in game. Assuming the texture was made in an editor that supported the 16-bit color depth (The GIMP does not support over 8-bit color).
I'm not suggesting we use the patch, just interested in how it would affect the game's look.
|
|
|
Logged
|
|
|
|
fromhell
|
|
« Reply #8 on: January 22, 2007, 09:51:20 PM » |
|
Anything can save 16-bit and Q3 doesn't have 16-bit or 8-bit TGA support either. Do you mean to say 16-bit channel support?
It might benefit HDR, but we don't have that yet XD
|
|
|
Logged
|
asking when OA3 will be done won't get OA3 done. Progress of OA3 currently occurs behind closed doors alone I do not provide technical support either.new code development on github
|
|
|
tw3k
Lesser Nub
Cakes 0
Posts: 143
|
|
« Reply #9 on: January 22, 2007, 10:55:18 PM » |
|
If you do use PNG, use pngcrush.
|
|
|
Logged
|
|
|
|
erachude
Nub
Cakes 0
Posts: 29
|
|
« Reply #10 on: January 23, 2007, 02:55:40 AM » |
|
it'd be redundant because OA uses PK3s which is ZIP and can provide compression for TGAs. makes sense, why use a compressed image format if the folders are going to be compressed anyway. i've been looking at a wikipedia page that compares file formats.... http://en.wikipedia.org/wiki/Comparison_of_graphics_file_formats...and .tga compares pretty favorably to jpeg. jpeg has a maximum of 24bit colour and is patented (although it's disputed), whereas tga can do 32bit colour and has no patent. tga makes more sense. something i've noticed, is that ubuntu show's thumbnails for some tgas but not others. i tried opening them in gimp and resaving them, but while it generated thumbnails it lost the transparency. does anyone know a way of generating thumbnails for tgas that doesn't mess them up? ---edit--- also, tga can do transparency, but jpeg can't.
|
|
« Last Edit: January 23, 2007, 03:23:14 AM by erachude »
|
Logged
|
|
|
|
fromhell
|
|
« Reply #11 on: January 23, 2007, 02:59:44 AM » |
|
that's because paint shop pro 5 (the app i used to do these 32-bit TGAs in) actually saves the 32-bit TGA with a 24-bit TGA header, causing programs to "properly" not recognize the alpha channel. Strange, isn't it
|
|
|
Logged
|
asking when OA3 will be done won't get OA3 done. Progress of OA3 currently occurs behind closed doors alone I do not provide technical support either.new code development on github
|
|
|
erachude
Nub
Cakes 0
Posts: 29
|
|
« Reply #12 on: January 23, 2007, 03:21:07 AM » |
|
that must be annoying. is paint shop pro 5 able to save the images in another 32bit format which has transparency? if so it might be worth, saving to that and then running a script that would convert that format to 32bit tga. it wouldn't make any difference to the running of the game, but it would allow people to work on the textures without knackering the transparency.
|
|
|
Logged
|
|
|
|
fromhell
|
|
« Reply #13 on: January 23, 2007, 03:31:13 AM » |
|
It can save 32-bit PNG fine!
|
|
|
Logged
|
asking when OA3 will be done won't get OA3 done. Progress of OA3 currently occurs behind closed doors alone I do not provide technical support either.new code development on github
|
|
|
erachude
Nub
Cakes 0
Posts: 29
|
|
« Reply #14 on: January 23, 2007, 04:00:20 AM » |
|
that's a good start. i'm going to go hunting for an easy way to convert 32bit pngs to 32bit tgas.
|
|
|
Logged
|
|
|
|
dmn_clown
Posts a lot
Cakes 1
Posts: 1324
|
|
« Reply #15 on: January 23, 2007, 01:28:25 PM » |
|
Do you mean to say 16-bit channel support?
16-bit per color, which would require HDR in the engine and probably new image editors on our part (Cinepaint and photoshop are the only image editors I know of that handle the high end image formats). that's a good start. i'm going to go hunting for an easy way to convert 32bit pngs to 32bit tgas.
Imagemagik or graphicsmagik
|
|
|
Logged
|
|
|
|
erachude
Nub
Cakes 0
Posts: 29
|
|
« Reply #16 on: January 24, 2007, 07:13:19 AM » |
|
i'm looking at getting something working with the gimp. there's a tga plugin... http://registry.gimp.org/plugin?id=237...that saves tgas with alpha channels. hopefully with the 32bit header. i know that gimp can do batch jobs from the command line, so hopefully it will be able to convert a load of 32bit pngs into 32bit tgas. sadly my pc is still in bits from the move, so it will be a while before i can try this out.
|
|
|
Logged
|
|
|
|
iLeft.bye
Member
Cakes 1
Posts: 187
|
|
« Reply #17 on: July 26, 2007, 07:43:47 PM » |
|
|
|
|
Logged
|
|
|
|
|