[gdal-dev] gdalwarp interpolation artifacts

[Roger André]

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<http://pobox.com/%7Ewarmerdam>
>> 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/8ddad4ed/attachment.html