Opened 20 years ago
Closed 10 years ago
#709 closed defect (fixed)
problem with resampling 16-bit data
Reported by: | Owned by: | warmerdam | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
We've noticed a problem with reprojecting full 16-bit images when using biliner or bicubic: the output image is speckled, presumably due to over/underflow. As verification, using the 20041210 snapshot we recklessly replaced all occurrences of "GInt16" with "GUint16" in gdalwarpkernel.cpp and the problem went away. The command line to reproduce is just: gdalwarp.exe -t_srs EPSG:4326 -rb f.tif ff.tif where f.tif is a simple 1-banded, 1Kx1K, unsigned, 16-bit geotiff -- whose dynamic range uses all 16 bits. I'll attach the two images if I can figure out how, otherwise I can email them as required.
Change History (5)
comment:3 by , 20 years ago
For now I have altered the PerformWarp() method o avoid using the "short" series of functions for anything except the nearest neighbour operations which don't require any interpretation of the 16bit data. This means UInt16 data now goes through the generic interface which is significantly slower, but should be accurate. Eventually we should look at implementing GUInt16 versions of the short functions where performance justifies the effort. I have confirmed correct operation for biliniear and cubic resampling now.
comment:4 by , 20 years ago
On reflection, I think we really need to implement high performance versions of the short functions for unsigned shorts. Reopening till that is completed.
comment:5 by , 10 years ago
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
I don't think there's problem anymore with warping, although specialized warper instances probably not exist for all datatypes, but the template based approach in trunk should make that much easier if needed
Note:
See TracTickets
for help on using tickets.