This issue was brought to our attention by a user that is interested in using the near-infrared (NIR) band in orthorectified, reflectance corrected images in Alaska. The user noted that the NIR cell values in the lakes they are interested in analyzing are predominantly NoData in the delivered images.
The heart of the problem appears to be the use of 0 (zero) as the assumed NoData value when reading the source NITF. The NoData value of 0 is then inherited by the output image. This is a problem for two reasons:
A post-stretch cell value of 0 is not necessarily the same as the absence of value.
As a result of the projection to the target coordinate system, legitimate NoData values are necessary around the outside of the image content. Due to the inherited NoData setting, gdal fills these cells with the value 0.
The result is that two different types of cells, zero reflectance value and the absence of value, are encoded as the same pixel value. From there, it is difficult to re-differentiate these types of cells.
Below is a snip of the NIR band from one of these images. Cells with the value 0 are colored red; all other values are displayed on a grayscale.
The following snippets are where the NoData value is set (via the -srcnodata option) for the source image, which is then inherited by the output image.
The gdalwarp option -dstnodata allows for the output image to be written with a different NoData value than the input. This could be set, per-band, to a value that is not within the valid output range of the given product.
There is not always an obvious NoData value, however, as some of the product combinations use the full range of their type. For instance, the ns option (no stretch) with Byte type (UInt8) uses all values as it is compressing from an 11-bit source raster to an 8-bit output raster.
Next steps
Calculate the post-stretch valid ranges and select NoData values outside of those ranges (where possible).
Background
This issue was brought to our attention by a user that is interested in using the near-infrared (NIR) band in orthorectified, reflectance corrected images in Alaska. The user noted that the NIR cell values in the lakes they are interested in analyzing are predominantly NoData in the delivered images.
The heart of the problem appears to be the use of 0 (zero) as the assumed NoData value when reading the source NITF. The NoData value of 0 is then inherited by the output image. This is a problem for two reasons:
The result is that two different types of cells, zero reflectance value and the absence of value, are encoded as the same pixel value. From there, it is difficult to re-differentiate these types of cells.
Below is a snip of the NIR band from one of these images. Cells with the value 0 are colored red; all other values are displayed on a grayscale.
Current Code
The function lib.ortho_functions.WarpImage is responsible for writing the output image.
The following snippets are where the NoData value is set (via the
-srcnodata
option) for the source image, which is then inherited by the output image.Possible change
The gdalwarp option -dstnodata allows for the output image to be written with a different NoData value than the input. This could be set, per-band, to a value that is not within the valid output range of the given product.
There is not always an obvious NoData value, however, as some of the product combinations use the full range of their type. For instance, the
ns
option (no stretch) withByte
type (UInt8
) uses all values as it is compressing from an 11-bit source raster to an 8-bit output raster.Next steps
Calculate the post-stretch valid ranges and select NoData values outside of those ranges (where possible).