[gdal-dev] gdalwarp interpolation artifacts

Tue Sep 30 13:33:27 EDT 2008

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<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/ce613065/attachment.html