[WMS CONNECTION] Reprojection of PNG images loses transparency

[dmorissette]

PNG map images obtained via WMS CONNECTION to CubeWerx (cubeserv) servers will 
lose their transparency if they are read by the GDAL interface and then 
reprojected... which means that those layers will completely overwrite the 
layers underneat.

OTOH, if the map slide is not reprojected, then the native MapServer link to GD 
is used to read the PNG and then the transparency is not lost... and the layer 
displays fine on top of other layers.

Frank added support for PNG transparency in GDAL, but it doesn't seem to work in 
this case... is it something we do wrong in setting the offsite color before 
calling GDAL, or maybe the transparency is lost in the resampling code?

[dmorissette]

Here is the note that Frank wrote when he updated GDAL for transparency... maybe 
some of that info can help?

Frank Warmerdam wrote:
> 
> At Daniel's request I have implemented properly "NODATA" support for
> the PNG and GIF formats in GDAL.  In GIF, if there is a transparent
> color index, it will be reflected through GDAL as an alpha value of
> 0.0 for that color index in the paletted, as well as a nodata value
> returned from GetNoDataValue().  The nodata valuei s what gets used by
> MapServer to set the "offsite" value.  Note that as part of this effort
> I found I had to upgrade to the latest version of libungif in GDAL.
> 
> I have also done this for PNG.  In the case of PNG palleted images can
> have a separate alpha value for each entry in the palette, which I reflect
> in the paletted returned by GDAL.  However, MapServer currently ignores
> the paletted alphas (this sort of blending is not part of the MapServer
> model currently).  To work around this, I have GDAL also return a nodata
> value for paletted images as long as there is only one transparent entry
> in the color table.
> 
> If the PNG file is greyscale I also potentially return a nodata value,
> if present in the file.
> 
> That means that any remote WMS server that returns paletted PNG files
> with a single transparent entry can be properly recognised by GDAL
> (and the MapServer cascading overlay capability).  However, if a
> remote WMS returns RGBA images, as some currently do, we have no way
> of recognising the transparency.  There are also "color compression"
> issues in the case.
> 
> For GIF I didn't modify the write to support transparency but for
> PNG I did.
> 
> I haven't tested any of this in MapServer ... I will leave that to
> Daniel.  Let me know if there are any problems.
> 

[dmorissette]

Note: this is not an urgent issue any more as we are able to access the layers 
when they are not reprojected, but if possible we should try to fix this down 
the road.

[fwarmerdam]

Daniel, 

If you can supply an example PNG that demonstrates the problem I would be
willing to dig into this. 

[dmorissette]

MapServer .map file that demonstrates the problem

[dmorissette]

I attached a mapfile that requests a map in EPSG:42101 with PNG layers that 
support only lat/lon... forcing a reprojection and demonstrating the problem.

The following URLs can also be used to fetch the individual PNG image slides 
that MapServer would request:

http://www.cubewerx.com/demo/cubeserv/cubeserv.cgi?VERSION=1.1.1&LAYERS=POLBNDL_
1M%3AFoundation&QUERY_LAYERS=POLBNDL_1M%3AFoundation&FORMAT=image/png&TRANSPAREN
T=TRUE&REQUEST=GetMap&WIDTH=400&HEIGHT=300&SRS=EPSG:4326&BBOX=-174.651483,34.247
673,-10.287010,83.615210&EXCEPTIONS=application/vnd.ogc.se_inimage


http://www.cubewerx.com/demo/cubeserv/cubeserv.cgi?VERSION=1.1.1&LAYERS=ROADL_1M
%3AFoundation&QUERY_LAYERS=ROADL_1M%3AFoundation&FORMAT=image/png&TRANSPARENT=TR
UE&REQUEST=GetMap&WIDTH=400&HEIGHT=300&SRS=EPSG:4326&BBOX=-174.651483,34.247673,
-10.287010,83.615210&EXCEPTIONS=application/vnd.ogc.se_inimage

[fwarmerdam]

Daniel, 

I looked at the png returned by CubeServ.  It appears that it is a 32bit
RGBA file for which we don't recognise transparency since it can't be easily
rendered down to an offsite value.  Each pixel has a potentially independent
alpha value.  Is it possible to request CubeServ return other variants of
PNG? 

warmerda@gdal[420]% gdalinfo test.png
Thu Dec 13 09:59:46 2001: GDAL: GDALOpen(test.png) succeeds as Portable Network
Graphics.

Driver: PNG/Portable Network Graphics
Size is 400, 300
Coordinate System is `'
Metadata:
  Software=CubeSTOR 2.11.1 for Oracle 8.0 on Linux
  Creation_Time=13 Dec 2001 14:50:25 +0000
  Geo.BoundingBox=-174.651483 34.247673 -10.28701 83.61521
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,  300.0)
Upper Right (  400.0,    0.0)
Lower Right (  400.0,  300.0)
Center      (  200.0,  150.0)
Band 1 Block=400x1 Type=Byte, ColorInterp=Red
  Min=0.000/0, Max=255.000/0
Band 2 Block=400x1 Type=Byte, ColorInterp=Green
  Min=0.000/0, Max=255.000/0
Band 3 Block=400x1 Type=Byte, ColorInterp=Blue
  Min=0.000/0, Max=255.000/0
Band 4 Block=400x1 Type=Byte, ColorInterp=Alpha
  Min=0.000/0, Max=255.000/0
Thu Dec 13 09:59:46 2001: GDAL: GDALClose(test.png)


I will add the PNG to this bug report for reference. 

[fwarmerdam]

RGBA PNG file from cubeserv

[fwarmerdam]

Actually, reviewing the mapraster.c code, I think it is not too hard to 
handle RGBA images in the RGB code, and just map any alpha=0 pixels to the
offsite value.  

I will try to do that this week. 

[dmorissette]

Thanks for checking this Frank.

Cubeserv advertizes only one type of PNG (image/png), so I don't think there is 
any way to request a paletted PNG based only in the XML capabilities.  I'll try 
to double-check with someone at Cubewerx, but even if there was a way, that 
would probably be a hack.

GD does recognize the transparency in those RGBA images, would it not be 
possible to mimic its behavior?  I didn't check what it does, but could we for 
instance return any pixel with an alpha=0 as the same transparent colour (no 
matter what the RGB values are)?  Or maybe that would break other apps that 
expect to receive RGBA values?  Could something like this be done in drawGDAL() 
then?

[dmorissette]

Oh... I just saw your other comment Frank... I guess you can ignore my 
suggestion which is equivalent to what you just suggested.

[fwarmerdam]

OK, I have modified mapraster.c's drawGDAL() so it correctly handles alpha
values in the existing RGB code.  However, I find this doesn't usual resolve
the problem with cubeserv pngs because mapraster.c's drawRaster() function
will use the gd-png support, if available, in preference to the gdal support
for png.  The gd-png code does _not_ support alpha layers, and so an error occurs.

Hmm, well in the case of reprojecting it would work since then the gd support
is avoided and the gdal code is used instead.  

Anyways, I have done what I intended to do, though it isn't clear to me
whether this fully resolves the original problem.  Is any further action
required?

[dmorissette]

Thanks for this Frank.  Transparent PNGs read by GD used to work for me when I 
was testing this bug, at least on one of our machine (running RH7.1).  Maybe 
newer versions of libpng+GD do support transparency coming from RGBA while older 
ones don't.

Anyway, what I'll do is force PNG's to be rendered through GDAL if they come 
from a WMS connection.  It's just a simple test and I already did had to do that 
for JPEGs for a reason that I forgot now.

[fwarmerdam]

Daniel, 

I believe this is resolved.  You might want to verify, but I think this
bug can be closed.

[dmorissette]

Yes, marking as fixed.  I tested with the attached sample mapfile and it works 
with both 3.6 and 3.7