Opened 16 years ago
Closed 16 years ago
#2415 closed defect (fixed)
floating point nodata representation problems in VRT/PAM
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.5.3 |
Component: | GDAL_Raster | Version: | 1.5.0 |
Severity: | normal | Keywords: | nodata precision |
Cc: | gaopeng |
Description
> I have a related problem. I use -FLT_MAX as NoData value for an img > image. > The NoData pixel value in the image is > -3.4028234663852886e+038 > The NoData value stored in .aux.xml is -3.40282346638529E+038 > The NoData value returned from GetNoDataValue is > -3.4028234663852901e+038 > > In ComputeStatistics, the following returns false, and as the result, > the NoData > pixels are included in stats computation. > > if( bGotNoDataValue && dfValue == dfNoDataValue ) > continue;
Change History (3)
comment:1 by , 16 years ago
Milestone: | → 1.5.3 |
---|---|
Status: | new → assigned |
comment:2 by , 16 years ago
A test was added in pam.py and the change was retrofit into 1.5 branch (r14751).
comment:3 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Version: | unspecified → 1.5.0 |
I have decided not to replicate this capacity in VRT for the time being.
Note:
See TracTickets
for help on using tickets.
I have applied a preliminary patch in trunk (r14679) to store nodata values in PAM files in hex encoded binary format to preserve exact precision. This seems to improve for a particular test case.
I'll extend this handling to the VRT code, and add a test case - hopefully tomorrow. If it works well, we should consider retrofitting the technique into 1.5.3.