[Gdal-dev] gdalwarp: getting rid of dark borders

[Frank Warmerdam]

On Thu, 06 Jan 2005 23:13:18 +0200, Tapio Sokura <oh2kku at iki.fi> wrote:
> Hi,
> 
> I'm a newbie with GDAL. So far I have managed to successfully use
> gdalwarp to transform raster images from one projection to another. As
> the target projection is different from the source, dark bands form to
> the edges to keep the image rectangle shaped. Is there an easy way to
> make gdalwarp automatically crop the map so that all the dark bands are
> removed, naturally with some inage data being cut out near the edges?
> 
> I've looked at the gdalwarp manual page and the switch to do that didn't
> jump up to my eyes. I see there is the -te parameter I can use to
> specify the extents of the new image. It works, but to use it I need to
> convert the image first and then manually find out the maximum map
> extents that result in a map with no dark edges. Is there an automatic
> way to do this?


Tapio, 

Good question.  There is no automatic way to do this.  In theory what
you need is something like the existing GDALSuggestedWarpOutput()
function used by gdalwarp, but that take the largest window completely
filled with data instead of the smallest window completely containing
all the data as is the rule now.  This isn't really something I have
ever wanted to do.
 
> A second thing came to mind on an optimal amount of pixels for the
> transformed image. Is there a rule of thumb or a simple algorithm to
> calculate the optimal amount of pixels to specify for -ts if I wanted
> the resulting image to look as good as possible without spending pixels
> on nothing? For now I've used the pixel count of the original picture as
> a starting point and increased the amount by about as many pixels as the
> dark map edges occupy in the final image.

Generally speaking you want ground size of a pixel to be the same
in the source and destination projection.  So if they are both meter
based projections you would normally compete the number of 
pixels based on deviding the selected extents by the pixel size in the
source image.  

GDALSuggestedWarpOutput() does something a bit more involved
because if the transformation is actually changing units or if the
region is highly distorted you might not be able to transfer the "pixel
size" literally from the source the destination image.  So it tries
to a diagonal pixel size on the source image and then compute
a destination resolution that has the same diagonal distance (after
transforming the source to destination).   

In effect, the important thing is to try and have the same "real"
pixel space on source and destination image. 
 
> And about the resampling algorithm. Is there a rule of thumb on which
> algorithm to use when the goal is to just change the projection and not
> significantly change the amount of pixels in the image? So far I have
> used the nearest neighbor algorithm. CPU usage (more complex algorithms)
> is not a problem. The images I've been transforming have been man-made
> maps with some 10-20 colors and anti-aliased lines.

If your image is pseudo-colored and thematic you *must* use 
nearest neighbour since changing pixel values would have 
peculiar effects.  But for continuous tone or fully RGB images bilinear
or cubic will generally give you smoother results.  The cubic in essence
helps fight the "smearing" effect that occurs with bilinear, but with the
risk of other odd effects. 

For your case I would just suggest you try cubic and bilinear, and 
compare.  If you like the cubic better than the bilinear then use it 
otherwise stick with bilinear.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent