Image Size Reduction

I've got a massive, massive world map image that I've rendered out in Vue 5. It's 350MB heavy when it's a 16-bit RGB, so I would like to decimate the color palette and reduce the image quality to save on size. In Photoshop, I can convert the image to 8-bit indexed color and get a PNG that's ~20MB, which is amazing savings, but it's only 256 colors. I want something a little richer, but the "indexed color" mode won't let me use more colors.

Do any of you know about a tool out there that can scale my image depth better than PS? Say, to thousands of colors? Any tips?

 

Hmm, i think indexed is always 256 Colors...

What especially do you need? Just smaller File-Size or less Data contained in the File?

 

If the image should be used in Unity, you will only get lower qwuality textures and not much saved space-wise, as Unity already compresses the texture for you. (Make sure you have texture compression enabled.)

So it is best not to worry about compressing the source image and just import a raw image with the most available details into the project. This way you can just edit the source image directly and don't have to worry about exporting the image for use in Unity.

If you are creating images for something else than Unity textures, I would reccomend using JPEG for anything that requires more than 256 colours. I don't know of any image formats that support more than 8bit indexed colour.

 

This is definitely for Unity. I'm sure Unity's compression is the best, but the filesize is so big that I'm willing to cull colors (and lose data), because I'm afraid lossless (or close to it) compression might not get my files as small as is convenient.

I'm not sure it works this way, but it would be nice to be able to reduce my image to, say, 1000 or so colors and save on space, then use Unity's compressor.

 

Ha! Well, it's a 8192x8192 image, but the camera will probably never see more than four 1024x1024 chunks at a time.

I'm obviously new to this. Photoshop thinks that reducing the depth to 8-bit will halve the file size (from the number in the lower-left corner), but when I save the image Finder says it's still about as large as the 16-bit image.

 

As already mentioned, the input doesn't matter to Unity, which uses DXT for final images no matter what. You could have 1 bit per pixel or 1,048,576 bits per pixel and the image will always be the same size when Unity publishes the game. Similarly, you can save the image as raw uncompressed data, or JPEG the heck out of it, and it will make no difference to Unity...so you might as well stick with lossless formats, because you won't gain a thing with smaller input files aside from loss in quality. So, 8 bit, 16 bit, or 32 bit makes no difference. In other words, don't bother trying to reduce the color palette; you're unlikely to gain much of anything.

It's a moot point, but just for the sake of info, you can't have more than 256 colors for indexed color regardless. 256 is the largest number you can store in a byte. Indexed color is named thusly because it uses an index for colors rather than specifying them directly. Color #47 (or whatever) could be red, purple, green, or whatever you want...all 256 colors in the index are stored in a list which is then referred to when drawing the image. So you can pick whichever 256 colors (or fewer) are best suited for the image at hand. A picture with lots of blue in it would naturally devote most of those 256 colors to various shades of blue.

If you want to go beyond 256 indexed colors, then you'd have to use more than one byte per pixel. So, for two bytes per pixel, you have a maximum of 2^16 possibilities instead of 2^8, which is 65,536...that would be one heck of an index! You'd need 192K per image just to store the data for the index...compared to 256 colors which only takes .75K for the index. Obviously that's not very efficient, so as long as you're using 2 bytes per pixel anyway, you might as well specify the colors directly. "Thousands of colors" on the Mac uses 5 bits for each of the red, green, and blue values, and the last bit is wasted I suppose, giving you 32,768 colors. 16-bit color uses 5 for red, 5 for blue, and 6 for green (because the human eye is more sensitive to green), which gives you 65,536 colors.

More than you ever wanted to know. It all ends up as DXT1 or DXT4/5 anyway when Unity is done with it (though your source images are never touched), so, like I said, a moot point....

--Eric

 

what are you trying to do? i was playing with vue and rendering textures out of it. i was using 4096 sized textures and wasn't happy with the file size or quality. so i started looking at layered texturing. 8192 just sounds like you're in for a world of hurt!

http://forum.unity3d.com/viewtopic.php?p=17983#17983

in that post you can download the assets for my terrain which shows you how i handled terrain texturing. it's not super detailed but not bad. with a little more effort it could be nice and it's really not that hard to do. it shows well on a pc laptop with 82815 graphics and the webplayer is only 2.7mb. with the 4096 texture it didn't look as good and the web player was 30mb!

 

One question: when you reduced the image to 8 bits indexed in PS, did you use dithering? If you opt to use indexed 8 bit afterall, you can experiment with different dither patterns or turn off dithering, this will effect image quality and file size.

 

Thanks for everything, guys. Learning a lot. I suppose that saving disk space would be the only good reason to reduce my image's quality, then (i.e. it won't make a difference to performance because the image will be resampled when rendered anyway)?

I checked out your terrain, pete, and again reconsidered using 3d, but the image I have is of an island with forests and crops and the surrounding ocean and a mountain that I'm just not sure I could do as well or with as much variety in 3D.

I'm going to press on, play with dithering, maybe cut the image back to 4097, and hopefully have something to show for it in a month's time!

 

ahh... i misunderstood world map as texture. so this is like a top down 2d scrolling map? click the left arrow and the map slides left or something? what about slicing it into smaller textures and scripting it to scroll? even so i'd bet it'll be pretty brutal on any machine - at 1024, that's 64 sizeable textures, at 512, it's 256 textures! can you reuse portions of smaller textures - ie tiling grass or clumps of trees? you know like old 2d mapping. or maybe i still misunderstand...

ps i'd bet dithered or not, index color won't give you what you want.

 

that's it exactly. Smaller tiling textures would probably be more efficient (and more traditional), but if there's one thing that Vue is really good at, it's detailed, high-res landscapes.

 

yeah but cut up the vue output. like the water off shore can be a tiled 128 texture or something. same with grass areas etc. you just have to take the slice and make it seamless in pshop or gimp. then maybe use layering like i did on the 3d terrain but on a flat plane.

don't know if/what the limit is on the number of textures in a material. thought i read something about it. i have 3 plus 4 alphas in one material and it renders correctly on intelgrated 815 (webplayer. haven't tried a standalone). you may need to stack multiple planes with transparency to keep the max number of textures per material to some level. really don't know...

[edit... just had another thought... i don't fully understand unity's loading. someone clarify plz. the first level loads everything. so if that's a load screen or menu and the actual game is level 2, the game assets wouldn't all load? so now what if you built a 3 x 3 grid of planes, chopped up your vue textures into 512s say and script an array to change texutres. or maybe it's dynamically generate planes and destroy any that are too far away. would this work for a ton of textures? would the unused textures get dumped too? still be a huge build. so not for web distribution.]

 

Wow. After a lengthy (2+ hour) compressing section, Unity was able to reduce the file size by a factor of 10, which is much more than adequate.

Thank you for having such excellent tools, OTEE!

 

Did you remember to slice it up first? ;-)

Graphics cards are limited in what res they support for their textures, so you want to use, say 2048x2048 slices...

Btw, how about showing a piece of it? I'm getting curious

 

Sure. Here is a high shot. It's detailed enough that one can zoom in pretty close.

 

nice! that's purdy for sure! interested to see where your take it.

nicholas, even at 2048 aren't you restricting it to higher end gpus? though i guess i somewhat am at a "who really cares" stage regarding optimizing. by the time i finish what i'm trying to do, higher end comps will probably be mainstream. but still...

 

I split it up into 1024 sized pieces so not as much needs to be loaded when zoomed far in. UVing it was one of the most tedious things I've ever done in my life.

 

good to know aras. see - what i call higher end are already mainstream!

marble... hahaha... uving is tedious! oh how i wish i could spend every day...