I realize that with any compression there will be artifacts, and especially a loss in visual quality when reducing to 4 bits. But I didn’t expect these kinds of artifacts:
Original PNG:
Artifact-laden PVRTC:
It added a bunch of dark spots across the top and even added a dark spot in an area (to the top left of the button) that is supposed to be completely transparent. Given that PVRTC is the only compression currently supported, surely there’s something that can be done to fix this?
There is nothing you can do about it.
You can choose between having your pixel data or having your pixel data drastically compressed by a factor of 8 (pvrtc 4, in this case I assume ARGB right?) or a factor of 16 (pvrtc 2) which just is impossible without destroying data.
As this looks like GUI so a menu, I would guess you don’t need compression. In most cases you don’t need it actually.
But when you use it, be aware the PVRTC is even more destructive than DXT1 or JPG and zooming in to it will show this very clearly.
well, there’s some things you can try, but it’s a bit of a pain… (for the last bigger project I worked on I had a couple of gui textures that had to be changed in such ways that the compression algorithm we were using, wouldn’t create visible glitches… = fun)
PVRTC is a block-based texture compression, that means that it works with groups of pixels. Problems mostly show up in high contrast areas where too many different extremes meet.
I’m no expert with compression algorithms, but I’ll at least try to explain what I have found out about PVRTC:
“It uses a representation that is based on the blending of two ‘low frequency’ signals using a high frequency but low precision modulation signal.” So when compressing, it takes your image, creates two small blurry versions and a modulation image. When putting it back together it calculates the value of each pixel like this: It scales the 2 small images back up and samples the 2 colors from the right location, and then decides which shade in between the 2 values to take based on the modulation image.
There’s an example on page 4 here, just look at Figure 3 and Figure 2: http://web.onetel.net.uk/~simonnihal/assorted3d/fenney03texcomp.pdf
(This is the doc I quoted above)
So the solution is very simple, isn’t it? Just try not to use more than 3 different colors in each 4x4 pixel block 
PS: What’s with unity spelling PVRTC “PRVTC” all over the place?
Thanks, that’s some good information. I had seen compression artifacts of all kinds before, but never seen dark spots distributed over my texture like that, or dark spots created out in the middle of nowhere where it is supposed to be transparent.
Oh well… that’s technology for ya.
Along these lines, I was doing more research on the skybox seam issue and found this good info on Apple’s web site:
http://developer.apple.com/iphone/library/qa/qa2008/qa1611.html
Unity uses Apple’s texturetool internally. If you run strings on Unity and you’ll see the invocation used is “–channel-weighting-perceptual”.
Great find! Is there a way to change that?
Like people say its block based compression.
It’s a pity. When I developmed DreamCast games back in 1998 (opps ten years already) I made a tool with more user control of the VQ data block.
Meaning you took an image and draw “protection” areas around the most important text etc. And then choose how many codeblock int the VQ Lookup table that protection area would have. With a bit of manual tweaking you could have more or less perfect compression.
This would only be applied to special textures of course or it was to time consuming.
I have not looked at the supplied VQ packing tools form the GFX card developer. But because Unity autocompress I don’t think i’ts a viable solution.
In the end the more “tilebased” your image are the better the compression will be.
Hmmm… I guess you could replace the texturetool inside Unity with a link to a script that calls the one installed by the iPhone SDK with a different set of arguments. I’m not sure it would help your particular case at all, but I’m willing to try it.
I ran the image you put on the forum through /Developer/Platforms/iPhoneOS.platform/usr/bin/texturetool for you. Here’s the results.
Source image (I had to edit the image to be square/power of two):
–channel-weighting-linear --bits-per-pixel-2
–channel-weighting-linear --bits-per-pixel-4
–channel-weighting-perceptual --bits-per-pixel-2
–channel-weighting-perceptual --bits-per-pixel-4
Hope this helps.
Thanks! It looks like in my case, the linear works better.
So if this is done, do you know if it is possible to toss the pre-compressed version into Unity, turn Unity’s compression off for that texture, and then have it work in the final build?
I have no idea if that’ll work, and I’ve got a tight deadline on a project today, but if your idea doesn’t work, I’ll throw together a script like I was talking about above.
What I don’t understand is that none of my compressed files looked as bad as yours did.
Good info Rob - the linear definitely looks better for GUI. I have been fighting this problem from day one with unity so far because all of my art to date has been more line-art oriented. GUI is absolutely line art oriented and we need to be able to set this in the Texture Import options.
Otherwise you just have to make them all 32 bit RGBA which is fine for buttons but not fine for a fullscreen background.
If we use Apples tool’s on the images in the assets folders will Unity try and re-compress on Build compile?