Using EZGUI, I might end up with a Sprite Atlas that shows ~400Kb on the hard drive, and yet, when I build the app, it ends up listing it as a 4 Mb resource. I’ve come to accept that compressing UI textures on iOS is simply not an option. And yet, I recently read that iOS supports png images just fine. Somewhere in all this, there’s a piece I’m missing…
Gigi.
Unity does not use source formats at all. Everything is always converted to an internal format, and what sort of compression you get depends on what you choose in the import settings. What iOS supports or not isn’t relevant.
–Eric
Maybe this thread is could be of any help ?
http://forum.unity3d.com/threads/162962-Unity-iOS-Image-Sizes issue ?
Not sure if I understood it entirely with my nonexistant programming understanding 
I was using png sequences and even empty pngs were 4mb each FRAME.
I made the same thing as a video with an alpha matte and it’s 300kb…
To quote Luke Skywalker, from the early moments of The Empire Strikes Back … “I care.”
Gigi
Well, Unity doesn’t care. 
In order to use PNGs “natively” it would have to be a feature built into Unity.
–Eric
But why it can’t support PNG/JPGs internally? It’s obvious that their compression is inferior, probably along the lines of what BMP offers, so why not go with better format? At worst it would mean slightly longer loading times for levels (because resources would be needed to decompress), no performance hit aside of that would occur (I’ve worked with several engines that can use PNG/JPG directly and worked as fluidly as Unity game of similar complexity - such as OGRE, Irrlicht and JMonkeyEngine, last being close in philosophy to Unity, but lack scene editor, so I know what I talking about).
Graphics cards do not use PNG or JPG. The compression Unity uses isn’t “their” compression, it’s the standard PVRTC compression that PowerVR chips on iOS devices use. It’s built in to the hardware, just like desktop hardware typically uses DXT compression. Either that, or it’s uncompressed entirely (ARGB32 etc.) if you don’t want any compression artifacts. What they could do is load PNG files as uncompressed textures (compressing to PVRTC on the fly isn’t feasible; it takes too long and Unity doesn’t own the PVRTC compression code anyway). You can do this yourself already, using TextAsset.bytes or whatever, but it’s kind of a pain compared to the normal Unity workflow. However all this does is save space on disk; there aren’t any other benefits. If you have lots of uncompressed textures, though, that can end up being meaningful. I expect eventually that option will be automated in Unity.
–Eric
^ This. With a pixel perfect UI, and lots of 2D assets in my apps, my textures routinely take 50% of my executable, which is tricky, when including 20 mins of audio and still trying to stay below the 50 Mb mobile limit. Unfortunately, the ‘compressed’ texture editor setting destroys UI textures. I look forward to seeing this as a feature.
Gigi
You can use PNGs if you want, but it’s a bit of work. Place the PNGs in the “Assets/StreamingAssets” folder. You can then load them with WWW and do www.texture to have Unity convert it to a texture. Yeah, it’s not pretty, I had to do it for an image gallery to load iPad retina-sized images, which were eventually placed online to conserve space (and I cached the downloaded PNGs in the persistentData folder).
This doesn’t help answer your question at all, but the download limit is no longer 50MB - it is now 100 MB.
It runs deeper than that. GPUs would have to care. (Edit: I see you covered this in a later post.)
Image file formats and texture formats aren’t really the same thing. One is designed to optimise for disk space, the other is optimised to maximise memory performance in a given GPU architecture. You can’t put a PNG format image into your video RAM and use it (or, if you could, it would be really slow).
@Gigi: With the above in mind, the source format of an image is completely irrelevant, because it’s just the file that you poke into the start of Unity’s content pipeline. Between there and the device you deploy it on it gets converted to a GPU-friendly format, the details of which depend on what you select in the import settings. If you leave it uncompressed then the raw colour data is used, not the raw file data. If you compress it then the compression used is something that works for the target GPU, which will almost always not be a file format that you’d ever use for generic editing or storage.
Don’t worry too much about the (uncompressed) truecolor UI textures causing the IOS download sizes to grow the same size. IPA files are compressed too, and truecolor images compress better than already compressed files. So in the end the truecolor UI texture might only cause a little higher size in the final binary. You can easily check that by zipping your output (*.app) folder. You will wonder how much it compresses even with the simple zip algorithm. You can use this simple method to compare the achievable compression ratios between builds using truecolor vs. builds using compressed UI textures. I bet you will seee not too much difference in the final zip size between the two. Apple does some scrambling which leads to less compressability too as a sideffect, so finally the compression ratio difference might be a bit higher though in the distributed, signed binary
Yes, iOS 3G/4G download limit was increased when iOS 7 was released. But with Google Play you don’t need to split your package if you keep it under 50 megs.
Why would you use PNGs anyway… they don’t have alphas inside of Unity. Even with Super PNG, alpha channels won’t import.
Not true. I am successfully using PNG textures with alphas for my desktop game and they work quite well. Though situation with IOS may be different, but textures with alpha works in Unity, you just need to use “transparent” shader.
Huh? I was using png sequences on android before I figured out how to do alpha videos. The pngs were definitely displaying alpha on a transparent shader.
The thing I don’t get is I had a png sequence with ARGB32 pngs and it was more than 50mb to build size. I made the same sequence as a video, also using ARGB32 and the same animation is under 300kb and looks exactly the same as the png sequence…
PNG is lossless compression (or no compression when used with Unity and using uncompressed import settings), video is heavily lossy compressed. It doesn’t look exactly the same at all, but it’s typically good enough—which is the point of video compression, to discard information that the eye doesn’t see well. Also, if not much changes between frames, the delta compression (which you can’t have with PNG sequences) will help a lot.
–Eric