#3658 closed defect (fixed)
gdalwarp writes erroneous nodata pixel at top left corner
| Reported by: | schmitzu | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.7.3 |
| Component: | Algorithms | Version: | 1.7.2 |
| Severity: | normal | Keywords: | |
| Cc: | schmitzu |
Description
The following command simply copies input to output:
gdalwarp \
-te 397000.0 5641990.0 397010.0 5642000.0 \ -tr 0.2 0.2 \ -of GTiff \ -srcnodata "255 255 255" \ -dstnodata "255 0 0" \ -r bilinear \ src.tif \ dst.tif
But dst.tif has a nodata pixel at the upper left corner. This happens only for interpolation methods bilinear and cubic. The problem exsists since version 1.6.1 at least.
The file src.tif is attached.
Attachments (3)
Change History (20)
by , 14 years ago
comment:1 by , 14 years ago
by , 14 years ago
| Attachment: | dst_rouault.tif added |
|---|
comment:2 by , 14 years ago
This is definitely not what I see. For clarification I attach my result dst.tif.
But wait. Meanwhile I've tried it under Windows with FWTools and I get the same result as you. What is your platform?
May be it's platform dependent or a problem with my build. My dst.tif is processed under Linux (SuSeV8 and V10), so I don't think it's version dependent. I will check further and it would be nice, if someone can try this under Linux.
by , 14 years ago
| Attachment: | dst_schmitzu.tif added |
|---|
comment:3 by , 14 years ago
I've tested with gdal trunk and branches/1.7 compiled by myself on Linux Ubuntu 8.04 64bit. I can also see the issue with the topleft pixel in your attached image. I have nothing in mind that could explain why you get this...
comment:4 by , 14 years ago
| Cc: | added |
|---|
comment:5 by , 14 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
I'm afraid you'll have to dig yourself since I cannot reproduce. Reopen if you can provide more elements
comment:6 by , 14 years ago
| Resolution: | worksforme |
|---|---|
| Status: | closed → reopened |
I've setup an ubuntu 10.04 virtual machine with VirtualBox under WinXP. With gdal-1.7.2 (tarball from download area, fresh build) I can reproduce dst.tif with red pixel in the upper left corner through aforementioned command. Hopefully I find some time to look further into this.
comment:8 by , 14 years ago
After some debugging I find out that the problem is *not* reproducible if the build is configured with --enable-debug. Only --disable-debug brings it back!
This doesn't make it easier to find...
comment:9 by , 14 years ago
I've tried a bit playing with -O2, -g and -DDEBUG flags on CFLAGS= and CXXFLAGS= lines in GDALmake.opt ? But I still get valid results in the cases I've tested. Could you precise the exact content of these lines when it works and when it doesn't, and the GCC version as well ?
comment:10 by , 14 years ago
My setup is Ubuntu 10.04 in Oracle VirtualBox 3.2.0,
with gcc V4.4.3 on board. I unpacked gdal-1.7.2 tarball
and did a usual ./configure --prefix=$HOME/var; make; make install.
So far nothing special and that uses the default --disable-debug.
That ends up in setting:
CFLAGS = -g -O2 -Wall -Wdeclaration-after-statement $(USER_DEFS) CXXFLAGS = -g -O2 -Wall $(USER_DEFS)
USER_DEFS is not set.
As stated before, I see the same behaviour under SUSE 8.2 and 10.x (gcc 3.3 and 4.1.2). So IMO it isn't very compiler/kernel specific.
comment:11 by , 14 years ago
schmitzu,
Could you try with the daily snapshot of the stable branch : http://download.osgeo.org/gdal/daily/gdal-svn-stable-2010.06.30.tar.gz ? And do you use internal or external libtiff (though I doubt it is really the issue)
comment:12 by , 14 years ago
I tried with the advised snapshot in my UbuntuVM, and got exact the same result as before. By default an external libtiff is used. Switching to internal one by "--with-libtiff=internal" doesn't make a difference. From the fact, that the effect can only be seen with interpolation methods bilinear and cubic, I guess the problem has to be searched there.
It's strange that you can't reproduce the situation. Thanks for your time so far.
comment:13 by , 14 years ago
| Component: | GDAL_Raster → Algorithms |
|---|---|
| Milestone: | → 1.7.3 |
| Resolution: | → fixed |
| Status: | reopened → closed |
OK, I finally installed a Ubuntu 8.10 VM and managed to reproduce the issue.
It was a numerical precision issue, specific to bilinear resampling in general case (that you hit because your source has nodata set), so this explains why it was so sensitive to compiler version, compiler flags, etc... For example when I ran gdalwarp under valgrind, the problem could disappear.
But beyond the numerical precision issue, this was indeed a regression that occured during GDAL 1.6 development where GWKGetPixelRow() was used in GWKBilinearResample() and could lead to skip source pixels. Previous implementations were probably OK on that use case.
Should now be fixed in trunk (r19957) and in branches/1.7 (r19958). Test added in r19959
comment:15 by , 14 years ago
rouault,
many thanks for your efforts! have you taken into account that cubic resampling has the same problem?! And is it fixed too?
comment:16 by , 14 years ago
In fact the issue with cubic resampling was just that it fallbacks to bilinear resampling on the edges, so it shares the same bugs ;-)
comment:17 by , 14 years ago
Backported to stable 1.7.2 and now it works, even with SUSE8 and SUSE10. Thanks again!
How did you check that there was a nodata pixel at the upper left corner ? I have tried and I don't see any nodata value. I'd note that GeoTIFF only supports one global nodata gvalue for all bands, so -dstnodata 255 0 0 ends up putting 0 as nodata value. But this is not an issue for your input image since the range of values doesn't include 0 or 255. I've attached the dst.tif I got