Opened 11 years ago

Closed 11 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 Changed 11 years ago by warmerdam

Milestone: 1.5.3
Status: newassigned

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.

  <PAMRasterBand band="1">
    <NoDataValue le_hex_equiv="000000E0FFFFEFC7">-3.40282346638529E+38</NoDataValue>
  </PAMRasterBand>

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.

comment:2 Changed 11 years ago by warmerdam

A test was added in pam.py and the change was retrofit into 1.5 branch (r14751).

comment:3 Changed 11 years ago by warmerdam

Resolution: fixed
Status: assignedclosed
Version: unspecified1.5.0

I have decided not to replicate this capacity in VRT for the time being.

Note: See TracTickets for help on using tickets.