CIB Transparency through GDAL

[warmerdam]

Frank Warmerdam <warmerdam@pobox.com> wrote:

> I have made a first crack at putting up CIB 10m data for Jacksonville, NC.
> The server is at:
>
>  http://www2.dmsolutions.ca:8099/cgi-bin/mswms_mpp1

I have added this to our corporate cascading map server as "CIB Demo
Server".  One thing I notice is that there is some bleed-through when
the CIB maps are put on top of other layers, as in (long URL):

http://www.cubewerx.com/demo/cubeview/cubeview.cgi?clickMode=zoom+in&layerToQuery=%28none%29&dataStores=CubeWerx&themes=BOUNDARIES&layers=Coastlines&action=+Go+&newScale=1.25M&newX=-77.23912772&newY=34.738032301&newImageWidth=600&newImageHeight=300&newImageType=PNG&newQuality=MEDIUM&zoomFactor=2&newSrs=4326+%28WGS+84%29&serverURL=http%3A%2F%2Fwww.cubewerx.com%2Fdemo%2Fcubeserv%2Fcubeserv.cgi&layersToPlot=Global+30+Second+Elevations%2C10meter+CIB%2CCoastlines&currentY=34.7380323010824&currentX=-7
7.2391277188667&currentScale=1.25M&currentImageWidth=600&currentImageHeight=300&currentSrs=EPSG%3A4326&currentImageType=PNG&currentQuality=MEDIUM

Near the center of the image, the green of the GTOPO30 layer shows through
the CIB map.  I suspect that there is confusion of white (0xFF) and
Transparent pixel values in the original data, the processing of the data,
and/or the generation of the 8-bit PNG image.  Chroma-key transparency
is a doomed art when dealing with natural images.

I also notice that the CIB image block doesn't get plotted into the last
two pixel rows of the image (and sometimes the last one or two pixel
columns).  I expect that the calculations of exactly what bounds of data
to fetch/plot is slightly off.  Remember that the pixels in GetMap images
represent areas and not a grid of points.

--------------------------+------------------------+--------------------------
Dr. Craig S. Bruce        | Ph.: 819-771-8303 x205 |             CubeWerx Inc.
Senior Software Developer |   Fax: 819-771-8388    |      Hull, Québec, Canada
csbruce@cubewerx.com      | http://www.csbruce.com |  http://www.cubewerx.com/
--------------------------+------------------------+--------------------------
             "Ladies and gentlemen, the money supply is secure."

[fwarmerdam]

The request (for a zoomed in area) that CubeView sends to MapServer looks
like this:

216.221.217.82 - - [02/May/2001:15:16:48 -0400] "GET
/cgi-bin/mswms_mpp1?WMTVER=1.0.0&REQUEST=map&SRS=EPSG%3A4326&BBOX=-77.24492577300208,34.75233490049896,-77.11740232284087,34.81609662557956&WIDTH=649&HEIGHT=325&LAYERS=JacksonvilleNC_CIB&STYLES=default&FORMAT=PNG&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE&EXCEPTIONS=WMS_XML
HTTP/1.0" 200 138538


Note that PNG format is being requested, and BGCOLOR is set to 0xFFFFFF.  It
appears the problem is that 0xFFFFFF is not being reserved properly as a
special color by stuff like the add_color() function in mapraster.c.

[fwarmerdam]

After discussions with Steve we determined the problem is that the
application at large, including mapraster.c, doesn't know to protect
themselves from using the transparent color.  I have modified add_color()
in mapraster.c to avoid using the background color if it is supposed to
be transparent, and this seems to have fixed the problem. 

The other edge effect problem is still there, and is particularly noticable
in the following url:

http://www.cubewerx.com/demo/cubeview/cubeview.cgi?clickMode=zoom+in&layerToQuery=%28none%29&dataStores=CubeWerx&themes=BOUNDARIES&layers=Barrier+Line+Features&newScale=625K&newX=-77.26589722&newY=34.76800118&newImageWidth=600&newImageHeight=300&newImageType=PNG&newQuality=MEDIUM&zoomFactor=2&newSrs=4326+%28WGS+84%29&serverURL=http%3A%2F%2Fwww.cubewerx.com%2Fdemo%2Fcubeserv%2Fcubeserv.cgi&layersToPlot=Global+30+Second+Elevations%2C10meter+CIB%2CCoastlines&currentY=34.7680011804618&currentX=-77.2658972155284&currentScale=625K&currentImageWidth=600&currentImageHeight=300&currentSrs=EPSG%3A4326&currentImageType=PNG&currentQuality=MEDIUM&imageClick.x=383&imageClick.y=138

[fwarmerdam]

This url more specifically demonstrates the problem.  I have checked the
cellsize, and it matches in X and Y to 10 or 11 decimal places, so that
does not appear to be the issue.

http://www2.dmsolutions.ca:8099/cgi-bin/mswms_mpp1?WMTVER=1.0.0&REQUEST=map&SRS=EPSG%3A4326&BBOX=-77.370219514279,34.668236358043,-76.898603990116,34.904044120124&WIDTH=600&HEIGHT=300&LAYERS=JacksonvilleNC_CIB&STYLES=default&FORMAT=PNG&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE&EXCEPTIONS=WMS_XML

[fwarmerdam]

I traced half the problem with the unfilled window to a poor approach
to rounding in mapraster.c's drawGDAL() dst_xsize/dst_ysize calculation. 
This has been corrected. 

The other half seems to be that the cellsize calculation in msAdjustExtent()
function in maputil.c is wrong:

  cellsize = MS_MAX((rect->maxx - rect->minx)/(width-1), (rect->maxy -
rect->miny)/(height-1));

Should be:

  cellsize = MS_MAX((rect->maxx - rect->minx)/(width), (rect->maxy -
rect->miny)/(height));

This change corrects things, but I will consult with Steve before applying
it since the effects could be far reaching.

[fwarmerdam]

Subject: Re: msAdjustExtent()
Date: Thu, 03 May 2001 10:36:57 -0500
From: "Stephen Lime" <steve.lime@dnr.state.mn.us>

MapServer considers the center of a pixel as the point associated with the
coordinate
of that cell. The extent has always been taken to be the distance between
centers of 
the first and last cells in a row or column, hence the width-1 or height-1. If
the extent
is
to be the distance from the outside of the first cell (left/top edge) and
outside 
(right/bottom) edge then width or height should be used. It's a subtle
difference and I'm
not sure which is correct. I went over this exact point several years ago and
settled on
the current calculations. (draw it on graph paper and it'll be clear)

Changing this has implications elsewhere although once fixed they shouldn't be
serious
I don't think. Just need to make sure all calcs use the same method for
cellsize.

Although WMS specs allow for non-square cells MapServer hasn't been updated to
support that. After 3.5 is released. So, for now a computed extent must be done.

Steve

[fwarmerdam]

I have modified mapwms.c to deflate the WMS extents in BBOX when preparing
the map->extents values.  I have adjusted drawGDAL() to take this formulation
of extents properly, and will modify mapresample.c accordingly as well. 
This seems to resolve the problem.