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é <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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é <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
