zero vs null

Rahkonen Jukka Jukka.Rahkonen at MMMTIKE.FI
Wed Aug 23 04:17:54 EDT 2006


Hi,

Reprojecting images one to one tends to give you those black edges because the original image boundaries does not match exactly the dimensions of pixels in the reprojected image. I know that some commercial image processing packages offer tools for creating a mosaic from the reprojected images and smudging the image seams so that the artifacts are not so obvious.  This can give quite a good looking results, even it is in a way fooling.  However, I concider as a better approach to mosaic the original images before reprojection. If the original image is large enough to contain the resulting, reprojected image totally within its extents then the reprojected image will have no black pixels. Original images does not need to be mosaiced physically but an image catalogue, virtual layer, or how do you want to call can be used instead.  If gdalwarp is to be used then GDAL/VRT virtual raster layer would is good for image source format.  So your work chain would have one more step: after adding projection make a GDAL/VRT with a gdal_merge.py script modified for this purpose, and reproject and split that VRT layer to given extents by using gdalwarp with "-te" switch. 

Regards,

-Jukka Rahkonen-

> -----Alkuperäinen viesti-----
> Lähettäjä: UMN MapServer Users List 
> [mailto:MAPSERVER-USERS at LISTS.UMN.EDU] Puolesta Zenon Panoussis
> Lähetetty: 23. elokuuta 2006 8:36
> Vastaanottaja: MAPSERVER-USERS at LISTS.UMN.EDU
> Aihe: [UMN_MAPSERVER-USERS] zero vs null
> 
> I am processing landsat images for use with mapserver. 
> Because of various problems (discussed in the the thread 
> "Landsat image tiffs") I have to use r.out.tiff to export the 
> scenes from grass, then add the geometry and projection with 
> gdal_translate and finally reproject the images with 
> gdalwarp. Doing this leaves an ugly black edge in the final 
> images in the area between the source projection and the 
> target projection. As far as I can figure, this is caused by 
> gdalwarp using 0 instead of null for nodata.
> 
> After a lot of hit-and-miss with -dstnodata and other such, I 
> found a workaround for this by running 'r.null map=xyz 
> null=0' on the source raster before exporting it. This way 
> the resulting image has R=0 G=0 B=0 where nodata used to be, 
> so those areas are identical to what gdalwarp introduces 
> during the reprojection, so I can get rid of all of it in 
> mapserver with a simple "OFFSITE 0 0 0".
> 
> This is not a good way of doing it though. For one, if an 
> image has valid data pixels that are black, they will be 
> removed too, as if they were nodata. For another, if I would 
> later want to run r.patch on these rasters, I'd be unable to 
> because null is gone.
> 
> There has to be some better way to get rid of the gdalwarp 
> reprojection differences, but I can't find it. I'm sure 
> someone here has had this very same problem before me and 
> solved it in a smarter way.
> 
> Any clues, please?
> 
> Z
> 



More information about the mapserver-users mailing list