Transparency problem.

[tbonfort]

Reporter: sfournier@dmsolutions.ca Date: 2003/09/08 - 17:35

Map used: GMAP.
Layer set to ON: popplace and prov_bound (all others are OFF).

When setting TRANSPARENT to TRUE in the map file with IMAGETYPE to PNG I get a
transparent background. But if I set IMAGETYPE to PNG24 I get some part of the
map transparent and some other not.

And other issue. If I remove the set of TRANSPARENT to TRUE from the map file
and try to set it to true from php mapscript it don't work. Here's a small script:

<?
header("Content-type: image/PNG");
dl("php_mapscript_40.so");

// Load la mapfile
$oMap = ms_newMapObj("gmap75.map");

// Set map tp transparent
$oMap->set("transparent", MS_TRUE);

// Draw map
$oImage = $oMap->draw();

// Output image
$oImage->saveImage("");
?>

This code don't output a transparent image what ever my output type is set to.

[tbonfort]

Author: dmorissette Date: 2004/10/20 - 00:46

Tested this with MapServer 4.3. There are 2 problems:

1- Setting IMAGETYPE PNG24 and TRANSPARENT TRUE in the mapfile doesn't produce a
transparent image. 

2- PHP MapScript $oMap->set("transparent", MS_TRUE); doesn't produce a
transparent image.

I'll create a new bug for #2 since it may affect SWIG MapScript as well. Let's
concentrate on #1 in this bug.

Frank: do you have any idea why we cannot produce a transparent PNG24?

[tbonfort]

Author: dmorissette Date: 2004/10/20 - 01:02

I have created bug 977 about issue #2 (setting map->transparent in mapscript)

[tbonfort]

Author: fwarmerdam Date: 2004/10/20 - 06:08

The semantics of the transparent flag are vague in the 24bit case.  Basically, 
if you select imagemode RGB then you can't really have a transparent image.
You need to select imagemode RGBA.  I see that msApplyOutputFormat() has
a special hook to convert the imagemode to RGBA if transparent is forced on
in an RGB image. 

Also, looking at msOutputFormatValidate(), an error message should be 
generated if the format transparent flag is set for an RGB image.  I see
that msSelectOutputFormat() calls the validate, so I'm surprised we don't
see the error message. 

Ah, yes, it is because setting an error with msSetError() doesn't do any good
if we don't propogate the error up the stack to force the error to be 
disgorged for the user.  I really feel that every msSetError() call ought
to be directed to msDebug() so we have a chance to see some of these "deep"
errors that are ignored at higher levels. 

OK, one step would just be to have msOutputFormatValidate() go ahead and
force format->imagemode to MS_IMAGEMODE_RGBA if format->transparent is
set.  

In summary, I don't see why setting the TRANSPARENT TRUE in the mapObj
in the mapfile wouldn't already force PNG24 to be installed as imagemode RGBA. 
However, setting an outputformat->transparent flag in isolation will not 
force the imagemode to RGBA.  

The support for forcing RGBA mode if TRANSPARENT was set was implemented
in mapoutput.c:1.15 (Jan 11, 2003) for Bug 249.  I see this bug shows the
version as 4.0.  Would 4.0.x releases include that change.  If you can 
demonstrate issue 1 (Setting IMAGETYPE PNG24 and TRANSPARENT TRUE in the 
mapfile doesn't produce a transparent image) still exists in 4.3 then assign
this bug to me, and I will track down why it isn't working right.

Hmm, I see a claim that this issue has been verified with 4.3.  I have tried
shp2img on the following ultra simple map, and it generated a transparent
RGBA output PNG.  Could whoever verified problem 1 please attach a counter
example that does demonstrate the problem?

NAME TEST
STATUS ON
SIZE 300 400
EXTENT 360015 4359225 371025 4373355
IMAGECOLOR 255 255 0

IMAGETYPE PNG24
TRANSPARENT TRUE

END # of map file

[tbonfort]

Author: fwarmerdam Date: 2004/10/20 - 22:58

I have changed msOutputFormatValidate() to fixup the imagemode to RGBA from
RGB if transparent is set.   I think this will help in some of the situations
I am pretty sure, possibly all of them.  

[tbonfort]

Author: dmorissette Date: 2004/10/20 - 23:47

Um... using shp2img or mapserv with your mini-mapfile (end of comment #3)
produces a transparent image, but rendering the same mapfile using PHP MapScript
doesn't produce a transparent image.

Here is the script I'm using:

<?
header("Content-type: image/png");

dl("php_mapscript_43.so");

$oMap = ms_newMapObj("bug425.map");
$oImage = $oMap->draw();
$oImage->saveImage("");

?>

Before I start to dig in the PHP wrappers to figure the differences, would you
be able to try with Python MapScript Frank?

[tbonfort]

Author: fwarmerdam Date: 2004/10/21 - 00:56

warmerda@gdal2200[90]% python
Python 2.3.3 (#1, Mar 16 2004, 16:37:35) 
[GCC 3.3.3 20040311 (Red Hat Linux 3.3.3-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mapscript
>>> map = mapscript.mapObj('blank.map')
>>> image = map.draw()
>>> image.save('out.png')
>>> 
warmerda@gdal2200[91]% file out.png
out.png: PNG image data, 300 x 400, 8-bit/color RGBA, interlaced

warmerda@gdal2200[92]% mapserv -v
MapServer version 4.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP
SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT
SUPPORTS=WFS_SERVER SUPPORTS=WCS_SERVER INPUT=EPPL7 INPUT=POSTGIS INPUT=OGR
INPUT=GDAL INPUT=SHAPEFILE DEBUG=MSDEBUG

Seems to work fine in Python MapScript.

[tbonfort]

Author: dmorissette Date: 2004/10/21 - 01:16

The image is RGBA, but how do you know that its background is transparent? I
don't see anything in the output above that says that. I get the same output
(same as you) from the 'file' command whether the image's background is
transparent or not. I actually have to use gimp to see if the BG is transparent.

[tbonfort]

Author: fwarmerdam Date: 2004/10/21 - 01:31

sorry, I did actually confirm with OpenEV that the alpha values are zero.
It just wasn't easy to paste that into the report. 

Note that while imageObj's are created with msImageCreateGD(), it is
msImageInitGD() that takes care of initializing the image to transparent.
Could it be that this isn't called in the PHP MapScript case?

[tbonfort]

Author: assefa Date: 2004/11/10 - 17:04

From the tests I did It seemed that the problem was when saving the image to 
stdout (as opposed to a file). I used a call to function msSaveImageBufferGD 
instead of doing the same work inside the php_mapscript.c. It seems now It 
produces the an RGBA with alpha values set to 0 from what I can see in OpenEv.

Daniel is it possible to make a quick check of the results ? If it is correct 
I can close the bug.

[tbonfort]

Author: dmorissette Date: 2004/11/16 - 19:04

That did it Assefa. Nice catch!  Marking fixed.

[tbonfort]

Author: bartvde@osgis.nl Date: 2004/11/24 - 19:11

This has side-effects for the way PNG24 images generated by Mapscript are
displayed with Internet Explorer (they have a grey background now). Does anybody
know a fix to this side-effect? I already have a pnghack installed on my website
which works for the scalebar, but not for the map image ... thanks in advance.

[tbonfort]

Author: bartvde@osgis.nl Date: 2004/11/24 - 19:23

The alpha channel is rendered correctly, unfortunately against the color taken
from bKGD chunk.

Browser examples: Microsoft Internet Explorer up to 6.0, Netscape up to 4.8,
Amaya 2.4.

The following could be a fix for IE, but I have no idea how easy this is ...

Include bKGD chunk in the image, and set the color to “expected average
background color under the image”. This way you have at least some control over
it and are not at the mercy of browsers' random decisions about the background
color. 

http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.bKGD

[tbonfort]

Author: dmorissette Date: 2004/11/24 - 20:27

Bart, unless there is a quick fix to this, I think you should file a new bug
instead of reopening a bug that's already been released. Just make sure you new
bug refers to this one.

Daniel

[tbonfort]

Author: bartvde@osgis.nl Date: 2004/11/24 - 20:46

bug 1089 has been opened for this new issue.