I.  Abstract

This report defines the Baseline OGC Testbed-21 Specification for GIMI. The Report specifies requirements and encoding rules for using the High Efficiency Image File Format (HEIF) for the exchange of georeferenced or geocoded imagery accordingly with the current version of GIMI. The specification deviates from the Geographic High Efficiency Image Format (GeoHEIF) candidate specification that was proposed by the previous OGC Testbed-20 initiative. The core sections of this document specifies the GIMI specification using the OGC modular specification approach and define the necessary Requirements Classes. Additional annexes define the fundamental information necessary for reading HEIF files, the approaches for tiles and overviews in HEIF and the TAI related boxes.

Please note that this document is internally referred to as an OGC Testbed 21 Report or more simply “this Report” or “this candidate standard”.

III.  Preface

The High Efficiency Image Format (HEIF) format, defined by Moving Picture Experts Group (MPEG), is a multipart data encoding that can support georeferenced imagery when used with the GeoHEIF extension that was proposed by the previous OGC Testbed-20 initiative. The GeoHEIF (Geographic High Efficiency Image Format) specification defines HEIF properties to include georeferencing information in one or more image items. These capabilities make it possible to include georeferencing information in a GIMI (GEOINT Imagery Media for ISR) imagery file, as GIMI is a profile of the HEIF standard. The OGC Testbed-21 initiative builds upon the achievements of the previous Testbed to define a baseline GIMI specification for the initiative that can then inform future versions of GIMI. This report documents the baseline specification of GIMI for this Testbed.

1.  Scope

This report defines the Baseline OGC Testbed-21 Specification for GIMI when the Testbed 21 started. GIMI extends HEIF by adding International Atomic Time (TAI) nanosecond formatted timestamps, information security markings of a dataset (including codewords, file control and handling, releasing instructions, declassification, and downgrading parameters), and content identification (Content ID). As HEIF has many possible ways of combining information and allows for several encodings, GIMI limits the content increasing the interoperability of the implementation. The scope of this document is limited to HEIF files containing still imagery, image sequences and motions imagery.

Advancements made during the Testbed 21 initiative are out of scope of this document, but are documented in a separate Testbed-21 report (Please refer to “OGC 26-011 Advancement of the GIMI Standard Report”). Convergency of the Geographic High Efficiency Image Format (GeoHEIF) candidate specification proposed by the previous OGC Testbed-20 initiative is also out of scope of this document.

2.  Conformance

This report defines several conformance classes for the GIMI format.

Requirements for one standardization target types (GIMI File) are considered:

Conformance with this candidate standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

In order to conform to this candidate standard, a software implementation shall choose to implement:

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

International Organization for Standardization (committee): ISO/IEC 14496-12:2022, Information technology — Coding of audio-visual objects — Part 12: ISO base media file format. International Organization for Standardization, International Electrotechnical Commission, Geneva (2022). https://www.iso.org/standard/83102.html.

International Organization for Standardization (committee): ISO/IEC 23008-12:2022, Information technology — High efficiency coding and media delivery in heterogeneous environments — Part 12: Image File Format. International Organization for Standardization, International Electrotechnical Commission, Geneva (2022). https://www.iso.org/standard/83650.html.

GEOINT Imagery Media for Intelligence, Surveillance, and Reconnaissance (ISR) (GIMI) — Volume 1 — Profile of ISOBMFF & HEIF — (2024-10-23) — Version 1.0.0 — NATIONAL CENTER FOR GEOSPATIAL INTELLIGENCE STANDARDS

4.  Terms, definitions and abbreviated terms

This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply.

ASCII encoded “four-character code” indicating data formatting requirements. Applications implement the 4CC code as a 32-bit big-endian unsigned integer with the first character in the MSB, last character in the LSB. There is no string termination

(source: NGA.STND.0076-01_V1.0.0_GIMI)

object-oriented container with a unique type identifier and length.

(source: MPEG)

an identifier in the FileTypeBox of a HEIF file that identify a specification to which the file complies. A HEIF file can have one brand and several sub-brands.

hardware or software component providing both an encode and decode function for imagery, video or other media types.

NOTE; Shorthand for coder-decoder

(source: NGA.STND.0076-01_V1.0.0_GIMI)

universally unique identifier providing enterprise-wide search and discovery ability. Content IDs apply to a specific sequence of bits representing a piece of content.

(source: NGA.STND.0076-01_V1.0.0_GIMI)

coordinate system that is related to an object by a datum

(source: OGC18-005r8,clause 3.1)

ordered series of coded images which may be associated with advisory timing and in which images may use inter prediction.

(source: MPEG)

high-precision, absolute, time scale derived from hundreds of precise atomic clocks from around the world and maintained as closely as possible to the Système International (SI) second. Current practice achieves a maximum deviation of approximately one second every 100 million years.

(source: NGA.STND.0076-01_V1.0.0_GIMI)

data which does not require timed processing, as opposed to sample data. Items may be an image or an instance of metadata

(source: MPEG)

form of compression where decompression results in a bit-wise identical result to the original. (source: NGA.STND.0076-01_V1.0.0_GIMI)

form of image compression where decompression results in an image containing differences, to some degree, from the original.

(source: NGA.STND.0076-01_V1.0.0_GIMI)

sequence of images, that when viewed (e.g., with a media player) must have the potential for providing informational or intelligence value. This implies the images composing the Motion Imagery are: (1) from sensed data, and (2) relate to each other both in time and in space. The sequence of images enables detecting motion of the sensor and/or objects within.

(source: MISB)

semantic web data format standard for representing interconnected data.

(source: NGA.STND.0076-01_V1.0.0_GIMI)

two or more-dimensional rectangular array of pixels derived from sensed phenomena indexed by row and column.

(source: NGA.STND.0076-01_V1.0.0_GIMI)

category of single images lacking the continuous temporal collection aspect of Motion Imagery. Without additional images, determining motion in a scene is much more difficult.

(source: NGA.STND.0076-01_V1.0.0_GIMI)

file containing only metadata (e.g. the georeference information) and pertaining to one or more GIMI files.

(source: NGA.STND.0076-01_V1.0.0_GIMI)

geometric shape with known properties that may or may not be the result of a tiling (tessellation) process. A tile consists of a single connected “piece” (topological disc) without “holes” or “lines”.

(source: OGC 19-014r3,clause 4.13)

The normative provisions in this standard are denoted by the URI

https://www.opengis.net/spec/GIMI/1.0-draft2

All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.

5.  Overview

The flexibility defined in the HEIF format determines the interoperability of the applications trying to read it. To improve the interoperability of HEIF files for geospatial applications, the GEOINT Imagery Media for ISR (GIMI) Profile of ISOBMFF & HEIF was defined by the National Geospatial Intelligence Agency (NGA) and adopted by the Geospatial-Intelligence (GEOINT) Standards Working Group (GWG). The GWG serves as the advisory body for advancing and enabling GEOINT standards across the US National System for Geospatial-Intelligence (NSG).

The GIMI standard proposes the mandatory inclusion of International Atomic Time (TAI) nanosecond formatted timestamps, information security markings of a dataset (including codewords, file control and handling, releasing instructions, declassification, and downgrading parameters), and content identification (Content ID) information supporting enterprise-wide uniqueness, traceability, effective search/discovery, and file releasability.

Requirements for declaring and encoding of metadata, along with requirements restricting the types and usage of coder-decoders (codecs) per type of media content ensure that files conformant to this standard maximize interoperability.

To facilitate interoperability with GEOINT Enterprise ontology structured metadata systems, this standard defines methods for encoding and carriage of metadata internal to the HEIF file, as well as methods for referencing metadata carried external to the HEIF file (i.e., a “sidecar” file in of Resource Description Framework (RDF) content encoded in the “TriG syntax”, and extension of “turtle”). GIMI defines essential metadata (content identification and high precision timing), security metadata, and generalized application metadata.

6.  Requirement Classes for GIMI core

7.  Requirement Classes for Content Identification

GIMI-essential metadata establishes an identity foundation for every item of media content. GIMI-essential metadata provides two capabilities: universal identification of media content and timestamp labeling of media content. Universal identification requires assigning a Content Identifier (Content ID) to every media data element. ISOBMFF defines an internal entity ID system to link media together. However, the ID system does not support global uniqueness. The purpose of this requirements class is to define global Content IDs.

8.  Requirement Classes for International Atomic Time

GIMI-essential metadata establishes an identity foundation for every item of media content. GIMI-essential metadata provides two capabilities: universal identification of media content and timestamp labeling of media content. Timestamp labeling requires assigning an absolute timestamp, i.e., an International Atomic Time timestamp (TAI timestamp), to every media content data element.

Within ISOBMFF, multiple forms of timing information exist within a file. ISOBMFF defines internal mechanisms for labeling absolute time, based on UTC, and for creating timelines for timed media, which supports the playout of the media. However, ISOBMFF timeline is not designed to facilitate high precision, nanosecond sensor measurements, analysis, and exploitation. With reliance on 32-bit integers, the longest presentation possible using nanosecond timing is less than five seconds. By implementing TAI timestamps independent of the ISOBMFF built-in timeline, GIMI achieves the necessary high precision measurement timing as well as being able to leverage the existing timeline tools for playout with standard consumer commercial video players.

The TAI time system is synchronous with the GPS time system (with a fixed offset of 19 seconds) and avoids problems associated with leap seconds, which occasionally occur in the UTC time system. Software applications with requirements for UTC time, such as for human display, convert TAI timestamps to UTC time with the proper leap second corrections and adjustments for time zones, etc. Applications need to be mindful of properly conveying to users the type and source of time when displayed.

TAI_timestamp is a 64-bit unsigned integer representing the number of nanoseconds since the TAI epoch of 1958-01-01T00:00:00.0. Each nanosecond is one billionth of a Standard International (SI) Second.

The data structures for TAIs are detailed in an annex of this document.

9.  Requirement Classes for Still Imagery

This section covers the nature of still imagery in general that can be in the forms for uncompressed and compressed imagery when stored in a HEIF file.

10.  Requirement Classes for Image Sequences

An image sequence is an ordered series of images. The following traits support image sequences:

11.  Requirement Classes for Motion Imagery

Motion Imagery is categorized in the Motion Imagery Standards Profile (MISP) into defined types or classes.

12.  Requirement Classes for Security Markings

This requirements class specifies how to include NSG Security XML markings in a GIMI file. This conformance class is only mandatory for all NSG GIMI files. All other activities are exempt from the use of the ‘sm01’ brand and exempt from the inclusion of GIMI Security XML markings. For example, commercial applications using NGA.STND.0076-01 are not required to have security markings and should not carry a security marking brand.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources [
  <!ENTITY uuid_urn "[a-f0-9]{8}-([a-f0-9]{4}-){3}[a-f0-9]{12}">
]>
<?xml-model href="../ISM/Schematron/ISM/ISM_XML.sch"
            type="application/xml"
            schematypens="http://purl.oclc.org/dsdl/schematron"?>
<?xml-model href="../ISM/Schematron/ISMCAT/ISMCAT_XML.sch"
            type="application/xml"
            schematypens="http://purl.oclc.org/dsdl/schematron"?>
<!-- Notices - distEditionBlockReplace -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning"
   vc:minVersion="1.0" targetNamespace="urn:us:mil:nga:stnd:0076:ism"
   xmlns:ism="urn:us:gov:ic:ism" xmlns:arh="urn:us:gov:ic:arh"
   xmlns:ntk="urn:us:gov:ic:ntk"
xmlns:gimi="urn:us:mil:nga:stnd:0076:ism"
   ism:resourceElement="true"
   xmlns:xhtml="http://www.w3.org/1999/xhtml-StopBrowserRendering"
   ism:compliesWith="USGov" ism:createDate="2011-12-01"
   ism:ISMCATCESVersion="202405" ism:DESVersion="202405"
   ism:classification="U" ism:ownerProducer="USA" version="202405"
   elementFormDefault="qualified">
  <xs:import namespace="urn:us:gov:ic:ism"
      schemaLocation="../ISM/Schema/ISM/IC-ISM.xsd" />
   <xs:import namespace="urn:us:gov:ic:arh"
      schemaLocation="../ISM/Schema/ISM/IC-ARH.xsd" />
   <xs:import namespace="urn:us:gov:ic:ntk"
      schemaLocation="../ISM/Schema/ISM/IC-NTK.xsd" />
  <xs:element name="GIMISecurity">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="gimi:File" minOccurs="1" maxOccurs="1"/>
      </xs:sequence>
      <xs:attributeGroup ref="ism:ISMRootNodeAttributeGroup"/>
      <xs:attributeGroup ref="ism:ISMResourceAttributeOptionGroup"/>
      <xs:attribute name="GIMISecVer" type="xs:string" use="required"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="File">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="arh:Security" minOccurs="1" maxOccurs="1"/>
        <xs:element ref="gimi:Content" minOccurs="0"
maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="Content">
    <xs:complexType>
      <xs:annotation>
        <xs:documentation>
          <xhtml:p ism:classification="U" ism:ownerProducer="USA">
            Lifted from ISM to avoid the questionable rule 511 about
            security elements being required to be resource node true.
          </xhtml:p>
        </xs:documentation>
      </xs:annotation>
      <xs:sequence>
        <xs:element ref="ntk:Access" minOccurs="0" maxOccurs="1"/>
        <xs:element ref="ism:NoticeList" minOccurs="0" maxOccurs="1"/>
      </xs:sequence>
      <xs:attribute name="id" type="gimi:ContentIDType" use="required"/>
      <xs:attributeGroup ref="arh:ResourceNodeAttributeGroup"/>
    </xs:complexType>
  </xs:element>
  <xs:simpleType name="ContentIDType">
    <xs:restriction base="xs:string">
      <!-- Leading digit of guide group is not zero, max 15 digits -->
<xs:pattern value="urn:uuid:[a-f0-9]{8}-([a-f0-9]{4}-){3}[a-f0-9]
{12}"/>
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

13.  Requirement Classes for Georeferencing by an RDF document

This requirement class describes how to add an RDF metadata document in a HEIF document. A HEIF writer needs to decide whether the RDF content is stored internal to a GIMI file or in an external resource, such as an RDF sidecar file.

@prefix cco: <https://www.commoncoreontologies.org/> .
@prefix tb21: <http://www.opengis.net/ont/tb21/> .
@prefix geosparql: <http://www.opengis.net/ont/geosparql#> .

<urn:uuid:1a9a5434-4a81-b48b-97da-774f33c0758b488b>
    tb21:hasCorr <urn:uuid:1ef7b441-ee30-5530-5379-65d6d13d0dce36bf>, <urn:uuid:489f6bd0-8425-c4c4-b867-1541a25c7927fbf8>, <urn:uuid:6f7451da-f2a4-391a-02da-6ae322b856bc9656>, <urn:uuid:75c6a59e-0de9-bb22-3389-262c07e64a6caf0e> ;
    geosparql:asWKT "POLYGON((138.498668 -34.800998,138.498669 -34.804844,138.494192 -34.800998,138.494192 -34.804844,138.498668 -34.800998))"^^geosparql:wktLiteral ;
    a tb21:RasterBoundsCorrGroup, geosparql:geometry ;
    rdfs:label "Correspondence Group"^^xsd:string ;
    cco:ont00001808 <urn:uuid:0a655014-e62a-0ead-5ae1-284b5a9304191932> .

14.  Media Types for any data encoding(s)

This document does not specify any particular media type for GIMI. As specified in https://www.iana.org/assignments/media-types/image/heic, media files will have the media image/heic only if the file conforms to requirements of the ‘heic’, ‘heix’, ‘heim’, or ‘heis’ brand, and contains at least one of those brands as a compatible brand. The media type image/heif will be used only if the file conforms to the requirements of the ‘mif1’ brand, and contains that brand as a compatible brand.

File extensions are not a clear indication of the file content. Commonly, the file extension identifies the primary use of the file. For instance, files carrying both Still and Motion Imagery may use a file extension of .heif or .mp4. Reader applications utilize brands in the FileTypeBox to determine which specification(s) a file and its contents conforms to, regardless of the extension.

Bibliography

[1]  Joan Masó Pau, Núria Julià Selvas, Rob Smith, Open Geospatial Consortium: OGC 24-040r1, OGC Testbed 20: GIMI Lessons Learned and Best Practices Report. Open Geospatial Consortium (2025). http://www.opengis.net/doc/PER/t20-D013.

[2]  International Organization for Standardization (committee): ISO/IEC 14496-15:2024, Information technology — Coding of audio-visual objects — Part 15: Carriage of network abstraction layer (NAL) unit structured video in the ISO base media file format. International Organization for Standardization, International Electrotechnical Commission, Geneva (2024). https://www.iso.org/standard/89118.html.

[3]  International Organization for Standardization (committee): ISO/IEC 15444-1:2024, Information technology — JPEG 2000 image coding system — Part 1: Core coding system. International Organization for Standardization, International Electrotechnical Commission, Geneva (2024). https://www.iso.org/standard/87632.html.

[4]  ISO/IEC: ISO/IEC 15444-16:2025, Information technology -JPEG 2000 image coding system — Part 16: Enhanced encapsulation of JPEG 2000 images into ISO/IEC 14496-12.. ISO, IEC (2025).

[5]  International Organization for Standardization (committee): ISO/IEC 23001-17:2024, Information technology — MPEG systems technologies — Part 17: Carriage of uncompressed video and images in ISO base media file format. International Organization for Standardization, International Electrotechnical Commission, Geneva (2024). https://www.iso.org/standard/82528.html.