Problem with background transparency (labels on maps)

[havard.tveite@…]

Frank Warmerdam wrote:
>I see.  It looks like background transparency is broken.  I would appreciate
>your filing a bug in Bugzilla on this including a minimal map file for
>producing the problem (ideally one with inline labels).

The problem is with IMAGETYPE png24 (OUTPUTFORMAT NAME png24 DRIVER "GD/PNG"
IMAGEMODE RGBA TRANSPARENT ON END).
White space shows up in and around the characters in labels when displayed
on a map. With IMAGETYPE png things are OK.

I do not know much about this, and the mistake may be mine.

I include a minimum(?) map file.
MAP
  NAME test
  IMAGETYPE png24
  #IMAGETYPE png
  OUTPUTFORMAT
    NAME png24
    DRIVER "GD/PNG"
    IMAGEMODE RGBA
    TRANSPARENT ON
  END
  SIZE 400 400
  EXTENT 0 6000000 1000000 8000000
  UNITS meters
  FONTSET /home/www/lib/fonts/font.list
  WEB
    IMAGEPATH "/home/ikf/ikfht/pub_html/mapserver/tmp/"
    IMAGEURL "/~ikfht/mapserver/tmp/"
    TEMPLATE /home/ikf/ikfht/pub_html/mapserver/o-kart/okart-37.html
  END #web

  SYMBOL
    NAME "circle"
    TYPE ellipse
    FILLED true
    POINTS 1 1 END
  END

  LAYER
    NAME fonttest
    TYPE POINT
    STATUS DEFAULT
    FEATURE
      POINTS 450000 6500000 END
      TEXT "BIG_AND_small test"
    END
    CLASS
      LABEL
        COLOR 0 0 0
        BACKGROUNDCOLOR 200 200 100
        FONT arial
        TYPE truetype
        SIZE 20
      END
    END # CLASS
  END

END

[fwarmerdam]

Steve,

I will try and take a first crack at this.  I presume the problem is lack
of proper transparency support in the text handling for 24bit output. 

[fwarmerdam]

Hi, 

My GD support invoice number is #30723.

I am encountering a problem drawing freetype text into a gdImage that
is truecolor, and has all the pixels set to a transparent value (0x7FFFFFFF). 
The alphaBlendingFlag is set to TRUE. 

This results in a call to gdft_draw_bitmap() with a ft_pixel_mode_grays bitmap
to be rendered into the gdImage.  It seems to select an appropriate level, but
at this point in the code things go wrong:

		  if (im->alphaBlendingFlag)
		    {
		      *tpixel =
			gdAlphaBlend (*tpixel,
				      (level << 24) + (fg & 0xFFFFFF));
		    }

In particular, the gdAlphaBlend() function ignores the transparency setting
of the *tpixel value, so even when rendering a transparent bitmap value
(level == 127) onto a transparent pixel (0x7fffffff) the resulting pixel
is set to white 0x00ffffff. 

I think this is a general flaw with gdAlphaBlend() that affects a number of
other places that I have worked around in the past, but it is not practical
for me to workaround this lowlevel function. 

I can produce a relatively small sample app that reproduces this problem
if necessary, but would prefer not to spend the time if you can see what
I mean clearly.  

I wouldn't be surprised if you didn't want to change the gdAlphaBlend() 
function since I presume it does what you intend, but I do need a way to
render text into true color gdImages without overriding background areas to
non-transparent values.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

[fwarmerdam]

Thomas Boutell has sent:

You can say better than I whether this is working correctly for your
purposes, unless you want to send me a test case, so please try this
alternate version of gdAlphaBlend; I will be very interested to
hear the results. I have done mathematical verification of this code
but, surprisingly, don't have a lot of good test environments for images 
with true alpha information in them! The new code is straightforward
and compiles cleanly. I'd be happy to look at any test cases you'd
like me to examine; in any case please do let me know right away
whether this meets your needs.

* * * 

int
gdAlphaBlend (int dst, int src)
{
  /* 2.0.12: TBB: alpha in the destination should be a
    component of the result. */
  return (
          (((gdTrueColorGetAlpha (src) *
             gdTrueColorGetAlpha (dst)) / gdAlphaMax) << 24) +
          ((((gdAlphaTransparent - gdTrueColorGetAlpha (src)) *
             gdTrueColorGetRed (src) / gdAlphaMax) +
            (gdTrueColorGetAlpha (src) *
             gdTrueColorGetRed (dst)) / gdAlphaMax) << 16) +
          ((((gdAlphaTransparent - gdTrueColorGetAlpha (src)) *
             gdTrueColorGetGreen (src) / gdAlphaMax) +
            (gdTrueColorGetAlpha (src) *
             gdTrueColorGetGreen (dst)) / gdAlphaMax) << 8) +
          (((gdAlphaTransparent - gdTrueColorGetAlpha (src)) *
            gdTrueColorGetBlue (src) / gdAlphaMax) +
           (gdTrueColorGetAlpha (src) *
            gdTrueColorGetBlue (dst)) / gdAlphaMax));
}

[fwarmerdam]

I have tried the revised gdAlphaBlend() and it does a nice job fixing
the problem.  I am a bit concerned that it may be costing more in terms
of performance than we really want to pay, but it does work.  

For now folks with this issue need to replace the gdAlphaBlend() in their
gd 2.0.11 with the one above.  It should appear in gd 2.0.12 when that is 
out.