Support GeoTIFF fields

[naivefun]

I'm using a tif file with gdalinfo command and the outputs is like this:

Driver: GTiff/GeoTIFF
Files: odm_orthophoto.tif
Size is 7671, 7781
Coordinate System is:
PROJCS["WGS 84 / UTM zone 14N",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-99],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","32614"]]
Origin = (702953.988113000057638,3978341.496489999815822)
Pixel Size = (0.049996153435006,-0.049996028788033)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=DEFLATE
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  702953.988, 3978341.496) ( 96d45' 1.31"W, 35d55'42.11"N)
Lower Left  (  702953.988, 3977952.477) ( 96d45' 1.67"W, 35d55'29.49"N)
Upper Right (  703337.509, 3978341.496) ( 96d44'46.02"W, 35d55'41.82"N)
Lower Right (  703337.509, 3977952.477) ( 96d44'46.37"W, 35d55'29.20"N)
Center      (  703145.748, 3978146.987) ( 96d44'53.84"W, 35d55'35.65"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
  Mask Flags: PER_DATASET ALPHA 
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
  Mask Flags: PER_DATASET ALPHA 
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
  Mask Flags: PER_DATASET ALPHA 
Band 4 Block=512x512 Type=Byte, ColorInterp=Alpha

However in ME the corner coordinates and some info is not parsed, the output of ME is:

[Exif IFD0] Image Width - 7671 pixels
[Exif IFD0] Image Height - 7781 pixels
[Exif IFD0] Bits Per Sample - 8 8 8 8 bits/component/pixel
[Exif IFD0] Compression - Adobe Deflate
[Exif IFD0] Photometric Interpretation - RGB
[Exif IFD0] Samples Per Pixel - 4 samples/pixel
[Exif IFD0] Planar Configuration - Chunky (contiguous for each subsampling pixel)
[Exif IFD0] Predictor - 2
[Exif IFD0] Tile Width - 512
[Exif IFD0] Tile Length - 512
[Exif IFD0] Tile Offsets - [240 values]
[Exif IFD0] Tile Byte Counts - [240 values]
[Exif IFD0] Unknown tag (0x0152) - 2
[Exif IFD0] Unknown tag (0x0153) - 1 1 1 1
[Exif IFD0] Unknown tag (0x830e) - 0.05 28575009627007793000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0.05
[Exif IFD0] Unknown tag (0x8482) - 0 0 0 0 0 -1839820918680221600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[Exif IFD0] Unknown tag (0x87af) - [32 values]
[Exif IFD0] Unknown tag (0x87b1) - WGS 84 / UTM zone 14N|WGS 84|

How should I parse these encoded values please? Thanks.

---

Some references:

• http://www.awaresystems.be/imaging/tiff/tifftags/modelpixelscaletag.html
• http://www.awaresystems.be/imaging/tiff/tifftags/geoasciiparamstag.html
• http://www.awaresystems.be/imaging/tiff/tifftags/geokeydirectorytag.html

[payton]

@naivefun

I'm assuming you mean how do you add those unknown tags into MDE, or are there other tags you want added? As far as adding/parsing the unknown tags displayed, you will need to create an entry for each tag in the respective directory (create a public static final int and then put it in the HashMap with the correct String name value). You can then parse this data in the respective descriptor. Most of the descriptors in the library have one main switch statement in the getDescription method that will allow you to return a unique String for each tag type. If we take the ExtraSamples tag (0x0152) for example, we would create a getExtraSamplesDescription method that returns a String. In the method, you would want to get whichever data type you need (in this case, int) from the directory. After that, you can manipulate/parse the data as needed. In your specific image's case, that should return something like "Unassociated Alpha" since the value is 2.

If you can provide a sample image, I could look more into the ones in the references you gave. Sometimes it helps me to open up the file in a hex editor (like Hex Fiend) to look at all of the raw bytes. Hex Fiend is nice because you can see the Ascii characters on the right panel (which would help for tags like the GeoAsciiParamsTag).

[drewnoakes]

GeoTIFF support was added to the .NET version of this library in https://github.com/drewnoakes/metadata-extractor-dotnet/pull/307. That PR should serve as a reference for any implementation on the Java side.

[don-vip]

GetUint64 and BigTIFF support should also be added from https://github.com/drewnoakes/metadata-extractor-dotnet/commit/309c29257806d9036b46273ade4c5f54e56302e4 and https://github.com/drewnoakes/metadata-extractor-dotnet/commit/23ae9538525461060007998b756fee5dadb5aeb7

[don-vip]

I'm working on it but I'm having a hard time to understand the differences in offset handling between the .NET and Java implementations (.NET seems in advance towards Java, but Java handles a "tiffHeaderOffset" absent in .NET implementation so I'm not sure how it fits in with the .NET evolutions)

[don-vip]

The field is gone in .NET since https://github.com/drewnoakes/metadata-extractor-dotnet/commit/2281ceaad7dff2b8d6ccebadc992c758c6b964c2

@drewnoakes I guess I should report this change to Java implementation as well to align them?

[richlv]

There seem to be 4 pull request referenced here that seem to be "approved" (?), but as they are in "open" state, they have not been merged yet - is that correct?