Support for HTJ2K Support

[cmheazel]

High Throughput JPEG 2000(HTJ2K) is a redesigned J2K format which provides much better performance than the original J2K algorithm. A summary for this format was presented to the Defense and Intelligence DWG on March 25, 2021. The DWG felt that a Geo-enabled form would be desirable and that we should follow the GeoTIFF model to achieve this. The proposed approach is to: 1) separate the GeoTIFF metadata from the TIFF file. 2) generate an encoding of the GeoTIFF metadata which is compatible wit the HTJ2K format. 3) pilot one or more implementations.

[rouault]

GeoJP2 (http://fileformats.archiveteam.org/wiki/GeoJP2) is something that already exists and is applicable to the whole JPEG2000 family, being at the JP2 box level rather than at the codestream level, so either for the classic Part 1 JPEG2000 or the new Part15 HTJ2K. I don't see anything new really needed. It should be noted that GeoJP2 is considered a bit as a deprecated approach compared to GMLJP2 (https://www.ogc.org/standards/gmljp2)

[rouault]

My recommendation: fix that issue as wontfix, or at the very least strongly coordinate with the SWG responsible for GMLJP2. There's no reason to have a different way of encoding georeferencing for regular Part-1 JPEG 2000 or for Part-15 HTJ2K. The difference between them is at the JPEG2000 codestream level, which is really an implementation detail for upper layers. GMLJP2 is capable of encoding both "known" CRS (with URN or URL), or custom ones (using GML CRS dictionaries). Using GML CRS dictionaries is probably quite complicated from an implementation point of view and has the caveat that the GML CRS encoding is based on an older version than ISO19111:2019 and is unlikely to be updated, but it exists. The GeoTIFF way to encode custom CRS has its own deficiencies (like inability to add new projection methods such as https://github.com/opengeospatial/geotiff/issues/56#issuecomment-506238420)

[EmDevys]

GeoJP2 (http://fileformats.archiveteam.org/wiki/GeoJP2) is something that already exists ... ..... It should be noted that GeoJP2 is considered a bit as a deprecated approach compared to GMLJP2 (https://www.ogc.org/standards/gmljp2)

GeoJP2 specification (a degenerate GeoTIFF file inside a uuid JPEG 2000 box) is no longer available (since Lizard Tech integration in Extensis company). It seems there is no company nor authority handling or maintaining this specification. However it is widely supported, as it seems to be realtively easy to implement (by software supporting GeoTIFF) for georeferencing imagery. Whether it is to be considered as "deprecated approach compared to GMLJP2" is to be discussed. Now that GeoTIFF is also an OGC standard, such discussion make sense in the OGC, but stakeholders having an interest in Geo JP2 exist outside the OGC.

[EmDevys]

My recommendation: fix that issue as wontfix, or at the very least strongly coordinate with the SWG responsible for GMLJP2. There's no reason to have a different way of encoding georeferencing for regular Part-1 JPEG 2000 or for Part-15 HTJ2K. The difference between them is at the JPEG2000 codestream level, which is really an implementation detail for upper layers.

It seems that HTJ2K (ISO 15444-15) is compatible with JPEG 2000 (set of ISO 15444 standards), and to be considered as an extension of JPEG 2000 and its JP2 format (as well as JPX). For georeferencing HTJ2K, both the usage of GML in the asoc/XML box as specified in GMLJP2, or the usage of a degenerate GeoTIFF file inside a uuid box) appear as potential options. I would agree that this topic (issue) should be discussed with GMLJP2.SWG in order to decide how it should be handled. Within the scope of GeoTIFF standard, it should presumably not be considered as an issue (IMHO).

[joanma747]

Funny thing could be to discuss here if the GMLJP2 strategy could (completely) replace the current approach for GeoTIFF. GeoTIFF already has a method to include a string, so it can also contain a XML fragment :-)

This idea is similar to https://github.com/opengeospatial/geotiff/issues/78

[joanma747]

links are not available that we can always use a timemachine: http://web.archive.org/web/20151028081930/http://www.lizardtech.com/download/geo/geotiff_box.txt

2.0 The GeoTIFF Box

The GeoTIFF box provides a simple mechanism for a JP2 file to have the same level of geospatial metadata as is provided by the widely supported GeoTIFF standard, using the normal GeoTIFF implementations.

2.1 UUID

The UUID for this box is

static unsigned char geotiff_box[16] = { 0xb1, 0x4b, 0xf8, 0xbd, 0x08, 0x3d, 0x4b, 0x43, 0xa5, 0xae, 0x8c, 0xd7, 0xd5, 0xa6, 0xce, 0x03 };

2.2 Box Contents

This box contains a valid GeoTIFF image. The image is "degenerate", in that it represents a very simple image with specific constraints:

. the image height and width are both 1 . the datatype is 8-bit . the colorspace is grayscale . the (single) pixel must have a value of 0 for its (single) sample

The TIFF image is to be encoded in little endian format. [Note that an early and possibly unreleased MSI encoder seems to have used big endian form, but the GeoTIFF data appears corrupt.]

The intent is that any compliant GeoTIFF reader/writer will be able to read/write this image.

Note that the TIFF image properties -- width, bitdepth, etc -- do NOT reflect the image properties of the JP2 image. These image properties are not to be used in the interpretation of the geospatial metadata.

Other TIFF image properties maybe present; if so, they should be similarly ignored.

[ If the TIFF image properties do not meet the constraints above, the geospatial information represented by this box should be considered to be undefined. ]

The GeoTIFF image may contain TIFF metadata tags. These should be ignored; they do not apply to the JP2 image.

The GeoTIFF image may contain any number of GeoTIFF keys, as allowed by the GeoTIFF standard. These keys define the geospatial metadata of this box and of the JP2 image itself.

[joanma747]

There was no objection to transfer this issue to the GMLJP2 group in today telecon. It will be done in a week time if nobody else objects by email.

One of the conclusion is that there should be no reason to have a different way of encoding georeferencing for regular Part-1 JPEG 2000 or for Part-15 HTJ2K and all should use the same GMLJP2.

[joanma747]

This depends on TIFF but this beyond our capacity of control TIFF. Other formats have this capabilities and embedding in TIF could be too much. There are efforts done to support many codecs already in this direction but many libraries does not read it.