Opened 23 years ago
Closed 23 years ago
#4 closed defect (fixed)
CIB Transparency through GDAL
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL Support | Version: | 3.5 |
Severity: | normal | Keywords: | |
Cc: |
Description
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¤tY=34.7380323010824¤tX=-7 7.2391277188667¤tScale=1.25M¤tImageWidth=600¤tImageHeight=300¤tSrs=EPSG%3A4326¤tImageType=PNG¤tQuality=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."
Change History (7)
comment:1 by , 23 years ago
Status: | new → assigned |
---|
comment:3 by , 23 years ago
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¤tY=34.7680011804618¤tX=-77.2658972155284¤tScale=625K¤tImageWidth=600¤tImageHeight=300¤tSrs=EPSG%3A4326¤tImageType=PNG¤tQuality=MEDIUM&imageClick.x=383&imageClick.y=138
comment:4 by , 23 years ago
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
comment:5 by , 23 years ago
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.
comment:6 by , 23 years ago
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
comment:7 by , 23 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
Note:
See TracTickets
for help on using tickets.