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