[gdal-dev] gdalwarp interpolation artifacts

Tue Sep 30 16:36:14 EDT 2008

The problem will be in all methods if I recall correctly, but to  
varying degrees. In the original resampling method, they all use  
kernels of varying sizes. When said kernel would sample against the  
edge of the image, it defaults to bilinear resampling (I think).  
Cubicspline has the largest kernel size, so it will have the largest  
artifact line. But cubic will also run up against the edge of the  
image, so it will also have artifacting, but the line will be narrower.

One thing you could try is changing the amount of memory that gdalwarp  
uses. Once it can fit more pixels in RAM, the chunks it works on will  
be larger.
~Seth

On Sep 30, 2008, at 11:33 AM, Roger André wrote:

> Well, the good news is that the artifacts don't seem to be present  
> when I use the plain "cubic" resampling method.  The bad news is  
> that the the quality of that method isn't good enough for me to  
> use.  I think my solution is going to have to be that I manually cut  
> pieces out of the low-res mosaic that overlap one-another, then  
> resample them to a size below what will cause the artifact (since I  
> *think* it's a size related problem), cut out the edge artifacts,  
> and then remosaic them into a full data set.
>
> I'm afraid that if I spend a bunch of time now trying to get a newer  
> version of gdal working, I'm going to get into an install death- 
> spiral that I can't get out of.
>
> Seth, can you comment as to whether you think the problem should  
> actually only exist in the cubicspline method?  From reading the  
> changelogs, it sounds like the error should be present in the other  
> methods as well.
>
> Thanks.
> --
>
>
>
> On Tue, Sep 30, 2008 at 9:37 AM, Roger André <randre at gmail.com> wrote:
> Hi Seth and Frank,
>
> Thanks for the feedback.  I just finished reading the changelog link  
> that Seth sent and all I can say is, "Wow, nice job!"
>
> I did some further testing last night using a single GTOPO30 tile,  
> and doing a 10x upsample.  The artifacts are present in it at  
> columns 6000 and 12000, so I think we can rule out that  
> gdal_merge.py is introducing the error.  I'm testing the cubic  
> resampling operator this morning, in the hopes that it won't produce  
> the error.  Since it seems to require a very large scaling  
> difference, it also takes a bit of time to run the test.  I'll let  
> you know what I find when it's done.
>
> Regarding running the latest code from trunk, I'm not sure if I can  
> do that.  I'm currently using the gdal implementation in the Linux  
> version of FWTools-2.0.6 because I am unable to get all of the  
> dependencies installed that I need for a source-compiled version of  
> gdal to work properly on my system.  I think I remember seeing some  
> traffic from Mateuz in the recent past that indicated he used  
> FWTools to build against.  I'll see if I can figure out what he was  
> doing.  If I recall correctly, Frank wasn't a huge fan of this  
> technique though. ;)
>
> Thanks again,
>
> Roger
> --
>
>
> On Mon, Sep 29, 2008 at 10:34 PM, Seth Price <seth at pricepages.org>  
> wrote:
> I agree with Frank, this sounds like the bug that I reported (and  
> fixed) here:
> http://trac.osgeo.org/gdal/ticket/2327
>
> (Although it became a log of my alterations to the warper kernel,  
> which was well beyond the scope of the original bug.)
> ~Seth
>
>
>
> On Sep 29, 2008, at 11:19 PM, Frank Warmerdam wrote:
>
> On Tue, Sep 30, 2008 at 4:30 AM, Roger André <randre at gmail.com> wrote:
> Hi List,
>
> I've hit the same problem twice now, and I'm pretty certain after  
> Round 2
> that I'm not introducing it.  Basically, I'm using gdal_merge.py to  
> mosaic a
> group of low-resolution, 32-bit floating point rasters together, then
> running "gdalwarp -ts xxx yyy -r cubicspline" on the mosaic to get a  
> higher
> resolution image.  I'm finding afterwards that there are linear  
> artifacts in
> the mosaic which run vertically through the mosaic, which look like  
> edge
> artifacts, but which are not located near the edge of either an  
> original
> low-res tile, or the resulting high res one.  I've tested the  
> interpolation
> of a single low-res tile in the area where the artifact is present  
> in the
> mosaic and I do not get the same results - the interpolated tile is  
> clear of
> artifacts.
>
> Is it possible that I'm hitting some sort of memory limit that is  
> causing
> only a certain number of columns to be interpolated at one time,  
> rather than
> the entire row?
>
> Roger,
>
> There have been some fixes to some of the gdalwarp interpolator
> code in recent months, so one hint is to ensure you try the latest
> "trunk" code to see if perhaps the problem is already fixed.
>
> Second, you may want to investigate the gdal_merge.py product
> carefully to ensure there aren't any bad pixels in it along the
> boundaries.
>
> Third you might try the cubic (instead of cubicspline) interpolator
> to see if it gives cleaner results.
>
> Beyond that a ticket submitted on the smallest test case that
> demonstrates the problem would be appreciated.
>
> 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080930/daa8fd78/attachment.html