Opened 13 years ago

Closed 13 years ago

Last modified 13 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 13 years ago.
Sample data and test program

Download all attachments as: .zip

Change History (7)

by ajain, 13 years ago

Attachment: NITFStats.rar added

Sample data and test program

comment:1 by Even Rouault, 13 years ago

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 by ajain, 13 years ago

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 by warmerdam, 13 years ago

Keywords: NITF statistics added
Status: newassigned

Investigating.

comment:4 by warmerdam, 13 years ago

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 by ajain, 13 years ago

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 by warmerdam, 13 years ago

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.