I share your experience with the -dTextAlphaBits=4
and -dGraphicsAlphaBits=4
flags. They appear not to work on all texts. The "fix" I came up with was to just render the image at 4 times the desired size, and then scale the image down. Luckily ghostscript has no problems rendering gigapixel PNG files.
update
Ghostscript (up to version 9) also seems to enjoy major problems when rendering transparent PNG's with a pixel count above 2.500.000 (i.e. 10 mb of pixel buffer). The transparent background suddenly turns white.
Drilling down the source of ghostscript, I found that when the pixel buffer size exceeds 10 mb, it switches to a different memory allocation scheme. More specifically, the image is rendered using device image32
instead of pngalpha
. Given the way the pngalpha
driver is implemented, it's whole purpose vanishes when gs decides not to use its pngalpha_fill_rectangle()
.
Luckily, there is a switch called -dMaxBitmap=N
to configure this parameter at runtime. This is mentioned in a workaround for a totally different bug dating back to 1999-01-15, see http://pages.cs.wisc.edu/~ghost/doc/AFPL/5.50/relnotes/index.htm.
Adding -dMaxBitmap=2147483647
solved a lot of problems for me. On 64 bit systems, this number can be higher.
A true fix would of course be to rework the pngalpha
driver so that it sets the background color to 0x7f000000
no matter the actual code path, but most systems have enough ram on board for the above trick to work.
I was trying to do some simple DIV backgrounds using a 1 pixel PNG with partial transparency to make a translucent box for some text above a background picture. It looked great in all kinds of browsers, until I tried the iPhone. It was doing the partial transparency, but with this odd greyish shade you speak of instead of the expected results.
I then tried those linked red & blue tests. They both looked fine the first time I viewed them, then hitting refresh caused them to go greyish! I tried again with a new browser window and it was back to looking proper, ahh the inconsistency you mentioned strikes again. Well then I just phyiscally rotated the iPhone, and as it went from landscape to portrait mode the colors shifted to the greyish versions!
All the W3C PNG partial transparency tests looked perfect on the iPhone. It did, however, fail the Gamma test. After ruling out the gamma as a possible cause I hunted this one down for hours, but got nowhere. I even made a gradient of my own that went all the way from 0 to 100% transparent to make sure it wasn't my process of creating the image. Sure enough, that worked perfectly, so my process is good.
Then I had this stroke of genius, what if the file were larger than 1 pixel? So I made it 2 pixels wide, and 1 pixel high, 20% transparent (alpha of 80%). Bam..it worked! I tried all kinds of combinations of 1x1, 1x2, 2x1, 2x2, 8x8. All of them worked properly except for the single pixel version.
I went back and checked the above linked tests, and see that they use 1 pixel images for all the shades. Ah ha!
And there you have it, Mobile Safari needs at least 2 pixels to work with for semi-transparent PNG files.
Best Answer
If you want to overlay images over images (and not images over form), this would make the trick:
Where overImage and backImage are PictureBox with png (with transparent background).
This is because, as said before, the transparency of an image is rendered using the back color of the Parent container. PictureBoxes haven't a "Parent" property so you have to make it manually (or create a cutom control of course).