Optimizing a PNG

Share things or chat about other subjects that don't fit in to the other forums.
Post Reply 
User avatar
6 Posts
 x 0

Post 03 Feb 2014, 12:18

I've been asked how come i get such small sizes in my textures, well, here's what i do...i'm going to share it with you guys but shhh!....don't tell anyone! :P

[video]https://vimeo.com/5685903[/video]
If you like our work please consider becoming a Supporter and get an ad-free experience.
User avatar
BDcraft Web Admin
6622 Posts
 x 439

Post 03 Feb 2014, 16:30

I think you confused him. Also don't post just random images ('tis in the rules :P).

It's an interesting video. Think it's a little above most users on the forum just because most people are just doing textures to fill voids ;)

I do wonder how your unoptimized PNG would stack up if I just threw it through my ImageMagick setup compared to all your fiddling and OptiPNG (probably not well, but still :P).
Profile pic by TsaoShin: https://www.deviantart.com/tsaoshin
User avatar
BDcraft Admin
578 Posts
 x 20

Post 03 Feb 2014, 16:40

Optimizing png files is useless...
A texture takes the same amount of memory in vram if it's a png, a bitmap, a tga or anything else. ;)
Optimizing png files will only (maybe) reduce ZIP file size...
If you like a post give it a diamond! :arrow_heading_up:
Have you tried Cubik?
User avatar
BDcraft Web Admin
6622 Posts
 x 439

Post 03 Feb 2014, 16:52

Sphax wrote:
Optimizing png files is useless...
A texture takes the same amount of memory in vram if it's a png, a bitmap, a tga or anything else. ;)
Optimizing png files will only (maybe) reduce ZIP file size...
Citation that it doesn't make a difference?

If a file is smaller it's going to use a smaller memory footprint to load and to access, surely? So if you can remove 25% of the file with optimization that can only be considered good unless you can actually prove otherwise.

I'm not sure why you're dragging anything about bmp, tga, etc. in to it.


Well my girlfriend explained it to me because she does software dev, etc. so yea. I see your point :P

And to explain it to everyone else, apparently (and this I never knew) when a texture is rendered to screen it's a bitmap regardless of its original form.

So basically no matter how small the source file is the rendering engine determines the size in memory (so with Minecraft let's just accept it'll be awfully large xD).
Profile pic by TsaoShin: https://www.deviantart.com/tsaoshin
User avatar
BDcraft Admin
578 Posts
 x 20

Post 03 Feb 2014, 19:36

HanFox wrote:
[...]
Well my girlfriend explained it to me because she does software dev, etc. so yea. I see your point :P

And to explain it to everyone else, apparently (and this I never knew) when a texture is rendered to screen it's a bitmap regardless of its original form.

So basically no matter how small the source file is the rendering engine determines the size in memory (so with Minecraft let's just accept it'll be awfully large xD).
Exactly!
Good point for your girlfriend! :)

A difference however is the alpha channel. If it doesn't exist, managing the texture will be a bit faster.

Also to know why, the texture is a bitmap in memory because it simply allows faster access to data. ;)
If you like a post give it a diamond! :arrow_heading_up:
Have you tried Cubik?
User avatar
Got Grungey First
385 Posts
 x 1

Post 03 Feb 2014, 20:40

Would this reduce download times? If so, awesome! :D
User avatar
6 Posts
 x 0

Post 04 Feb 2014, 01:56

yes, you are correct. textures are proccessed in vram as a collection of pixels. at this stage the only releveant factor in terms of performance is the dimensions of the map. (for 512x512 that would be exactly 1.5mb per) and the source file size is not taken into consideration...however in order to read and transfer resources from disk into vram there are a number of possible bottlenecks. primariy hard drive read speed. but also there is an overhead on much slower (than vram) system ram to perform the operation....and then there is the cost in proccessor time required to actually fetch the file, decode it and send it to the gpu's texture cache in it's bitmap form. (pci-e bandwidth is not a problem we can do anything about anyway so let's just ignore it)

this last point is what this method is meant to attack.... but you say hey wait a second...proccessors are so fast nowadays! .indeed, they are. but there are also faster, less expensive methods of decoding png data.

-"ok, fine. but what is this so called 'faster' method you speak of?"
suprisingly simple. 8 bit palettes are decoded 3 times faster than 24 bit ones.
-"and what about transparency?"
alpha values are indexed as another color in the color table so there's no "full" alpha channel to proccess.

after that it's up to your gpu to do the rest of the work.



note: (and another silly dialogue)
- "right, so what's the catch?"
Well, I've got these fine leather jackets.....
nah just kidding :D
as we all know, Java is a buggy beast. so make sure your image palette has at least 128 entries to avoid an old and obscure bug in J2SE involving pngplugin and elderberries (long story...don't ask)
but i don't think minecraft even use that. at least i've never had a problem with opimized textures, but it's worth noting
Post Reply