<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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.</div><div><br></div><div>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.</div><div>~Seth</div><div><br></div><br><div><div>On Sep 30, 2008, at 11:33 AM, Roger André wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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.<br> <br>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.<br><br>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.<br> <br>Thanks.<br>--<br><br><br><br><div class="gmail_quote">On Tue, Sep 30, 2008 at 9:37 AM, Roger André <span dir="ltr"><<a href="mailto:randre@gmail.com">randre@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div dir="ltr">Hi Seth and Frank,<br><br>Thanks for the feedback. I just finished reading the changelog link that Seth sent and all I can say is, "Wow, nice job!" <br><br>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.<br> <br>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. ;)<br> <br>Thanks again,<br><br>Roger<br><font color="#888888">--</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Mon, Sep 29, 2008 at 10:34 PM, Seth Price <span dir="ltr"><<a href="mailto:seth@pricepages.org" target="_blank">seth@pricepages.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I agree with Frank, this sounds like the bug that I reported (and fixed) here:<br> <a href="http://trac.osgeo.org/gdal/ticket/2327" target="_blank">http://trac.osgeo.org/gdal/ticket/2327</a><br> <br> (Although it became a log of my alterations to the warper kernel, which was well beyond the scope of the original bug.)<br> ~Seth<div><div></div><div><br> <br> <br> On Sep 29, 2008, at 11:19 PM, Frank Warmerdam wrote:<br> <br> </div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div> On Tue, Sep 30, 2008 at 4:30 AM, Roger André <<a href="mailto:randre@gmail.com" target="_blank">randre@gmail.com</a>> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi List,<br> <br> I've hit the same problem twice now, and I'm pretty certain after Round 2<br> that I'm not introducing it. Basically, I'm using gdal_merge.py to mosaic a<br> group of low-resolution, 32-bit floating point rasters together, then<br> running "gdalwarp -ts xxx yyy -r cubicspline" on the mosaic to get a higher<br> resolution image. I'm finding afterwards that there are linear artifacts in<br> the mosaic which run vertically through the mosaic, which look like edge<br> artifacts, but which are not located near the edge of either an original<br> low-res tile, or the resulting high res one. I've tested the interpolation<br> of a single low-res tile in the area where the artifact is present in the<br> mosaic and I do not get the same results - the interpolated tile is clear of<br> artifacts.<br> <br> Is it possible that I'm hitting some sort of memory limit that is causing<br> only a certain number of columns to be interpolated at one time, rather than<br> the entire row?<br> </blockquote> <br> Roger,<br> <br> There have been some fixes to some of the gdalwarp interpolator<br> code in recent months, so one hint is to ensure you try the latest<br> "trunk" code to see if perhaps the problem is already fixed.<br> <br> Second, you may want to investigate the gdal_merge.py product<br> carefully to ensure there aren't any bad pixels in it along the<br> boundaries.<br> <br> Third you might try the cubic (instead of cubicspline) interpolator<br> to see if it gives cleaner results.<br> <br> Beyond that a ticket submitted on the smallest test case that<br> demonstrates the problem would be appreciated.<br> <br> Best regards,<br> -- <br> ---------------------------------------+--------------------------------------<br> I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br> light and sound - activate the windows | <a href="http://pobox.com/%7Ewarmerdam" target="_blank">http://pobox.com/~warmerdam</a><br> and watch the world go round - Rush | Geospatial Programmer for Rent<br></div></div> _______________________________________________<br> gdal-dev mailing list<br> <a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br> </blockquote> <br> </blockquote></div><br></div></div></div> </blockquote></div><br></div></blockquote></div><br></body></html>