Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#5001 closed defect (fixed)

NITF driver does not handle images where the raster size does not match the subimage size

Reported by: kuhnboy Owned by: warmerdam
Priority: high Milestone: 1.9.3
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:
Cc:

Description

I have an image where NPPBH * NBPR = the JPEG subimage raster width and NPPBV * NBPC = the JPEG subimage raster height.

NCOLS is less than the size of NPPBV * NBPC (therefore it is less than the size of the JPEG subimage raster height). GDAL fails to process the image due to NCOLS not matching the raster height of the JPEG subimage.

But, the NITF spec says this is valid.

Per NITF Spec (http://www.gwg.nga.mil/ntb/baseline/docs/2500b/2500b.pdf):

NROWS: This field shall contain the total number of rows of significant pixels in the image. When NPPBV * NBPC > NROWS, the remaining last rows (NPPBV * NBPC - NROWS) shall contain fill data (that is, only the rows indexed 0 through NROWS -1 of the image contain "significant" data). The pixel fill values are determined by the application.

NCOLS: This field shall contain the total number of columns of significant pixels in the image. When NPPBH * NBPR > NCOLS, the remaining last pixels of each column (NPPBH * NBPR - NCOLS) shall contain fill data (that is, only the columns indexed 0 through NCOLS -1 of the image contain "significant" data). The pixel fill values are determined by the application.

Change History (4)

comment:1 by Even Rouault, 10 years ago

Can you share such an image ?

comment:2 by kuhnboy, 10 years ago

I cannot find such an image that I can share, but I will try to explain it and show the fix that we applied in our repository.

The JPEG compression standard requires that the image dimensions be in multiples of the minimum coded unit (MCU) block size of typically 16 pixels. Often certain types of imagery is generated in dimensions that are not a multiple of the MCU and therefore zero padding is added to the JPEG image. In the NITF Image sub-header there are the fields NROWS & NCOLS which represent the number of significant rows and columns respectively in the image. This is the actual size of the image minus the zero padding that the JPEG standard requires.

Currently the NITF dataset driver looks for NCOLS/NROWS to not match the JPEG Raster Width/Height and doesn't allow the file to be processed further. A patch would be to change the if block (nitfdataset.cpp line 721) to:

if( poDS->GetRasterXSize() > poDS->poJPEGDataset->GetRasterXSize()
    || poDS->GetRasterYSize() > poDS->poJPEGDataset->GetRasterYSize())
{
    CPLError( CE_Failure, CPLE_AppDefined,
              "JPEG data stream has smaller dimensions than the NITF file.");
    delete poDS;
    return NULL;
}

comment:3 by Even Rouault, 10 years ago

Component: defaultGDAL_Raster
Milestone: 1.9.3
Resolution: fixed
Status: newclosed

Thanks. Fixed in trunk (r25666) and branches/1.9 (r25667). I managed to generate such a file with GDAL actually. See the new nitf_70 test in r25666

comment:4 by Even Rouault, 10 years ago

The commit message is wrong. It should have read "NITF: allow reading JPEG-in-NITF where JPEG stream dimensions are larger than NITF dimensions (#5001)"

Note: See TracTickets for help on using tickets.