<div dir="ltr">Hi Seth and Frank,<br><br>Thanks for the feedback.&nbsp; I just finished reading the changelog link that Seth sent and all I can say is, &quot;Wow, nice job!&quot;&nbsp; <br><br>I did some further testing last night using a single GTOPO30 tile, and doing a 10x upsample.&nbsp; 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.&nbsp; I&#39;m testing the cubic resampling operator this morning, in the hopes that it won&#39;t produce the error.&nbsp; Since it seems to require a very large scaling difference, it also takes a bit of time to run the test.&nbsp; I&#39;ll let you know what I find when it&#39;s done.<br>
<br>Regarding running the latest code from trunk, I&#39;m not sure if I can do that.&nbsp; I&#39;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.&nbsp; I think I remember seeing some traffic from Mateuz in the recent past that indicated he used FWTools to build against.&nbsp; I&#39;ll see if I can figure out what he was doing.&nbsp; If I recall correctly, Frank wasn&#39;t a huge fan of this technique though. ;)<br>
<br>Thanks again,<br><br>Roger<br>--<br><br><div class="gmail_quote">On Mon, Sep 29, 2008 at 10:34 PM, Seth Price <span dir="ltr">&lt;<a href="mailto:seth@pricepages.org">seth@pricepages.org</a>&gt;</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 class="Wj3C7c"><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 class="Wj3C7c">
On Tue, Sep 30, 2008 at 4:30 AM, Roger André &lt;<a href="mailto:randre@gmail.com" target="_blank">randre@gmail.com</a>&gt; 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&#39;ve hit the same problem twice now, and I&#39;m pretty certain after Round 2<br>
that I&#39;m not introducing it. &nbsp;Basically, I&#39;m using gdal_merge.py to mosaic a<br>
group of low-resolution, 32-bit floating point rasters together, then<br>
running &quot;gdalwarp -ts xxx yyy -r cubicspline&quot; on the mosaic to get a higher<br>
resolution image. &nbsp;I&#39;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. &nbsp;I&#39;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&#39;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>
&quot;trunk&quot; 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&#39;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 &nbsp; | 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 &nbsp; &nbsp;| 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>