Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#3985 closed defect (fixed)

Statistics are not persisted for NITF format datasets

Reported by: ajain Owned by: warmerdam
Priority: high Milestone: 1.9.0
Component: GDAL_Raster Version: 1.8.0
Severity: normal Keywords: NITF statistics
Cc: rprinceley

Description

After computing statistics on the attached nitf data, the stats are not persisted with the dataset. This can be seen when GetStatistics? is called on the re-opened dataset instance from the sample test script used to reproduce the problem.

I also noticed that the destructor of NITFWrapperRasterBand is not called when the dataset is closed (my breakpoint is not hit while debugging) - indicating that there is a leak in the nitf driver.

Attachments (1)

NITFStats.rar (18.9 KB) - added by ajain 7 years ago.
Sample data and test program

Download all attachments as: .zip

Change History (7)

Changed 7 years ago by ajain

Attachment: NITFStats.rar added

Sample data and test program

comment:1 Changed 7 years ago by Even Rouault

r21897 /trunk/ (autotest/gdrivers/nitf.py gdal/frmts/nitf/nitfdataset.cpp): NITF: make PAM available at band level for JPEG/JPEG2000 compressed datasets (#3985)

As far as I can see, my debugger shows that NITFWrapperRasterBand destructor is called at dataset closing.

comment:2 Changed 7 years ago by ajain

The change seems to fix the problem partially. If stats are computed for the test data using ComputeStatistics? and GetStatistics? is called within the same running instance, valid stats are returned. But if I run the program again, but this time only call GetStatistics? (by commenting out the code that calls ComputeStatistics?), stats are not returned. I would have expected that the ComputeStatistics? during the first run would have persisted the stats.

Also, I am debugging using 1.8 version of GDAL sources - which is where I noticed that the destructor of NITFWrapperRasterBand is not called (using my test program).

comment:3 Changed 7 years ago by warmerdam

Keywords: NITF statistics added
Status: newassigned

Investigating.

comment:4 Changed 7 years ago by warmerdam

Amit, I have tested Even's changes in trunk and they seem to persist the statistics properly, including after a close and reload. I also tested that patch against GDAL 1.8 branch and it worked properly. Did you port his patch back into 1.8 for your testing?

I tried it with the 1.8-esri branch but merging was challenging due to divergence in the NITF driver.

comment:5 Changed 7 years ago by ajain

Resolution: fixed
Status: assignedclosed

Frank, thanks for testing this out...I had the code ported back properly, but I think there must have a build problem when I tested this locally earlier. I rebuilt GDAL 1.8 again, and I can see the stats persisted.

Thanks once again for looking into this, and I apologize for my mistake.

comment:6 Changed 7 years ago by warmerdam

Milestone: 1.9.0

I have backported the NITFProxyPamRasterBand implementation to 1.8-esri (r21956). I have confirmed that PAM statistics storage now seems to work properly with the test program.

Note: See TracTickets for help on using tickets.