Opened 16 years ago

Closed 16 years ago

#2353 closed defect (worksforme)

Sensor calibration

Reported by: arb Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc:

Description

There needs to be a mechanism for handling sensor calibration. For example a lot of satellite data is stored in 16-bit integers with an associated method of converting to floating-point physical units. The method might be a simple slope/intercept scaling factor, or there might be one for each band, or some bands might have dual-slope calibration, or there might be a look-up table, or ...

At the moment this information appears to be thrown away but maybe there is no standard way of representing it. However it would be nice if at least there were options, such as reading the integers, apply the calibration and work in floating point; or pass on the calibration to subsequent modules.

Take the example of reading a proprietary format, re-projecting it and writing out a standard format like GeoTIFF. Calibration information needs to be either preserved in the output format or applied to the output data.

Change History (2)

comment:1 by pvachon, 16 years ago

Hi,

I definitely agree that there are some places where this is an issue. A fairly good example of this is that many SAR image formats provide a LUT or coefficients for a polynomial describing the conversion of the DNs in the file to sigma_0, beta_0 or gamma calibrated values.

Perhaps it would be best to point out some sensors/data formats where this issue is prevalent, however, because this issue is very global and for some types of data implementing radiometric correction would be non-trivial. If this is SAR-specific, feel free to get in touch with me directly, and, if you're able to provide sample datasets, I can look into dealing with this issue.

Regards, Phil

comment:2 by warmerdam, 16 years ago

Resolution: worksforme
Status: newclosed

There is already a concept of an offset and scale associated with raster bands. This mechanism allows applications to find how to rescale integer values to physical units but it does not attempt to describe the physical units.

Some drivers do not implement the GetOffset() / GetScale() that could, and in other cases it is hard to work out proper values. If you believe there is a particular driver that isn't returning offset and scale when it ought to please note it here in this ticket.

There is no standardized model for non-linear scaling between integer pixel values and physical units. Metadata can store the transformation but it isn't part of the set of well defined metadata for GDAL.

Note: See TracTickets for help on using tickets.