Looking at the code, it appears that GDAL actually hard codes any TRE that takes anything that cannot be parsed as a string (e.g. nitfimage.c NITFReadICHIPB). So, for BANDSB with its EXISTENCE_MASK and SCALE_FACTOR would need to be hard coded as opposed to being defined just within the nitf_spec.xml. Is this the correct interpretation?
Thanks! Adam ________________________________ From: Brad Hards <br...@frogmouth.net> Sent: Wednesday, November 6, 2019 2:54 AM To: Edson, Adam Robert <are...@psu.edu>; gdal-dev@lists.osgeo.org <gdal-dev@lists.osgeo.org> Cc: Bradley, Eliza S <esb...@psu.edu> Subject: RE: [gdal-dev] python GDAL issue Hi Adam, https://github.com/codice/imaging-nitf/pull/196<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcodice%2Fimaging-nitf%2Fpull%2F196&data=02%7C01%7Care131%40psu.edu%7C1f5f02d357214ab1cac808d7628e8df2%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637086236748108876&sdata=r%2BZS3nYRN2M%2B7VFqmSJt%2F3lHXduFeMMIBfNALX9S43A%3D&reserved=0> is the work I did for my java implementation. The spec definition I came up should be directly applicable. However for it to work in GDAL, we need at least: * Support for parsing / using the IEEE 754 encoding (which I called type=”IEEE754”) * Support for parsing / using the 32bit integer encoding (which I called type=”UINT”) * Support for the “&” condition operator (for bitmask tests) * Unit tests I think I can hack my unit test code to output some test files. Brad From: Edson, Adam Robert <are...@psu.edu> Sent: Wednesday, 6 November 2019 1:36 AM To: Brad Hards <br...@frogmouth.net>; gdal-dev@lists.osgeo.org Cc: Bradley, Eliza S <esb...@psu.edu> Subject: Re: [gdal-dev] python GDAL issue Brad, Sorry it took so long to get back to you. I am interested in collaborating on this with you. Any help would be appreciated! Thanks! Adam ________________________________ From: Brad Hards <br...@frogmouth.net<mailto:br...@frogmouth.net>> Sent: Monday, October 14, 2019 6:16 PM To: Edson, Adam Robert <are...@psu.edu<mailto:are...@psu.edu>>; gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> <gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>> Subject: RE: [gdal-dev] python GDAL issue I think the problem is that there isn’t any real way to handle the IEEE-754 (or raw int/uint bitmask) in GDAL at the moment. Working through the part you’ve posted: S is the unit quantity The part that looks like: B\\0\\0\\0 is therefore the SCALE FACTOR, which is really IEEE 754-2008 binary encoded, and the existing TRE XML definition and parsing code doesn’t handle that case AFAICT. This part is the ROW_GSD and COL_GSD + units: 0030.00 M 0030.00 M In that case, I think there is a missing value in the TRE (because there has to be four bytes, and there are only three shown in your sample, which I assume is the test data that NGA derived from LANDSAT 8). I’ve also been looking at handling “weird” TREs better (on and off for a while). I have a Java implementation that shares the XML definition, and the plan is to add two new types to the field definition: <xs:attribute name="type" use="optional"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="string"/> <xs:enumeration value="integer"/> <xs:enumeration value="real"/> <xs:enumeration value="UINT"/> <xs:enumeration value="IEEE754"/> </xs:restriction> </xs:simpleType> </xs:attribute> (where UINT and IEEE754 values are new, and are binary encoded instead of string encoded). Happy to collaborate on this if you’re interested. Brad From: Edson, Adam Robert <are...@psu.edu<mailto:are...@psu.edu>> Sent: Monday, 14 October 2019 10:02 PM To: Brad Hards <br...@frogmouth.net<mailto:br...@frogmouth.net>>; gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> Subject: Re: [gdal-dev] python GDAL issue I am working on adding BANDSB and the other TREs listed in the SNIP document. I am not sure what you are asking for. However, here is the output from gdal.getMetadata('TRE') for the relevant portion of the BANDSB TRE SPECTRAL RADIANCE SB\\0\\0\\0\\0\\0\\00030.00M0030.00M-------M-------M \\0\\0DETECTOR<file://0/0DETECTOR> \x7fU This is the section from the radiometric_quantity field to wave_length_unit field. Thanks! Adam ________________________________ From: Brad Hards <br...@frogmouth.net<mailto:br...@frogmouth.net>> Sent: Saturday, October 12, 2019 1:51 AM To: Edson, Adam Robert <are...@psu.edu<mailto:are...@psu.edu>>; gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> <gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>> Subject: RE: [gdal-dev] python GDAL issue GDAL’s NITF encoding doesn’t appear to have BANDSB yet: https://github.com/OSGeo/gdal/blob/master/gdal/data/nitf_spec.xml<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgdal%2Fblob%2Fmaster%2Fgdal%2Fdata%2Fnitf_spec.xml&data=02%7C01%7Care131%40psu.edu%7C1f5f02d357214ab1cac808d7628e8df2%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637086236748118873&sdata=xuRz7pAyFvAKu69gUu9Rn%2BYVZvA%2FC2NWkhuC%2FCfbkgI%3D&reserved=0> It would definitely help to see how that file encodes it. Can you open the NITF file, find the part that starts with BANDSB0nnnn (where 0nnnn is some length value), and copy out the following 0nnnn characters? Brad
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
