[gdal-dev] python GDAL issue

Wed Nov 6 11:33:49 PST 2019

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 <bradh at frogmouth.net>
Sent: Wednesday, November 6, 2019 2:54 AM
To: Edson, Adam Robert <are131 at psu.edu>; gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Cc: Bradley, Eliza S <esb165 at 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 <are131 at psu.edu>
Sent: Wednesday, 6 November 2019 1:36 AM
To: Brad Hards <bradh at frogmouth.net>; gdal-dev at lists.osgeo.org
Cc: Bradley, Eliza S <esb165 at 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 <bradh at frogmouth.net<mailto:bradh at frogmouth.net>>
Sent: Monday, October 14, 2019 6:16 PM
To: Edson, Adam Robert <are131 at psu.edu<mailto:are131 at psu.edu>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org> <gdal-dev at lists.osgeo.org<mailto:gdal-dev at 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 <are131 at psu.edu<mailto:are131 at psu.edu>>
Sent: Monday, 14 October 2019 10:02 PM
To: Brad Hards <bradh at frogmouth.net<mailto:bradh at frogmouth.net>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at 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 <bradh at frogmouth.net<mailto:bradh at frogmouth.net>>
Sent: Saturday, October 12, 2019 1:51 AM
To: Edson, Adam Robert <are131 at psu.edu<mailto:are131 at psu.edu>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org> <gdal-dev at lists.osgeo.org<mailto:gdal-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191106/6ccdff75/attachment-0001.html>