Ticket #2415 (closed defect: fixed)

Opened 3 months ago

Last modified 3 months ago

floating point nodata representation problems in VRT/PAM

Reported by: warmerdam Assigned to: 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

06/10/08 00:41:16 changed by warmerdam

  • status changed from new to assigned.
  • milestone set to 1.5.3.

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.

06/22/08 00:15:08 changed by warmerdam

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

06/22/08 00:16:42 changed by warmerdam

  • status changed from assigned to closed.
  • version changed from unspecified to 1.5.0.
  • resolution set to fixed.

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