Public comment on candidate OGC BigTIFF Standard (OGC 21-061r1)
Submitted by: Narasimha Sharma Narayanam (@nsnarayanam)
Founder & CEO, Aganitha Space Technologies Pvt. Ltd
OGC CSAPI SWG · IEEE DMEW WG (voting member, GRSS Earth Observation Standards) · ISO/TC 211 · W3C WoT WG · IAF · FIET, ARAeS
Date: 9 May 2026
Document under review: OGC 21-061r1 (DRAFT)
Comment window closes: 24 May 2026
Comments below from someone who reads and writes BigTIFF rasters in production every working day. The same goal as the editor's: get the Van Damme / Eichhorn / libtiff work into OGC custody cleanly.
I have read through issue #5 and the points raised by IvanSanchez (units, offset reference frames, type disambiguation, the bits/bytes typo in A.1.1), art1pirat (offset definition, conformance edge cases, missing implementer guidance, UTF8 datatype), fmigneault (media types in RFC #6), and sub-issue #7. None of those are repeated below. What follows is new ground, plus a few defects in the PDF I haven't seen flagged anywhere.
Grouped loosely by type, not by priority. If only one of these gets read, please make it C1 (security).
A. Things in the document that look like template residue or factual errors
A1. The cover-page dates are placeholders. The cover lists Submission, Approval, and Publication Dates all as 2029-03-30. Annex C, the Revision History, has a single row: "2016-04-28, 0.1, G. Editor, all, initial version." Both look like template carryover from the AsciiDoc source. They will need real dates and a real history before approval. The 2021 Testbed-17 origin and the 2024–2026 SWG transitions probably belong in the history table.
A2. Annex A is labelled both informative and normative. The Annex A title page reads "CONFORMANCE CLASS ABSTRACT TEST SUITE (NORMATIVE)" but the heading immediately below says "ANNEX A (INFORMATIVE)" with "(NORMATIVE)" appended. Clause 2 (Conformance) clearly intends the abstract test suite to be normative, so the "(INFORMATIVE)" label needs to come out of the Annex A heading.
A3. Table 4 has a typo in the OFFSET column. Requirement 3, Table 4 (BigTIFF Tag structure) lists the byte offsets as 0, 1, 2, 4, 12. The first field (Tag identifying code) is uint16 and takes 2 bytes, so the second field should start at offset 2, not offset 1. The stray "1" looks like a footnote marker that has slipped into the offset column. Annex B Table B.3, which has the equivalent classic-TIFF layout, is correctly laid out and is a useful reference.
A4. Definitions §4.1 and §4.2 are circular. Both read "a modified data structure" without saying what is modified. A reader who comes to BigTIFF without knowing classic TIFF cannot get the distinguishing feature from these definitions. Suggested replacements:
4.1 big image file directory: a data structure containing the TIFF fields of a BigTIFF file, using 64-bit offsets and an 8-byte entry count.
4.2 big image file header: the 16-byte data structure at the beginning of a BigTIFF file, holding the byte-order indication, version number 43, offset size, reserved field, and the 64-bit offset to the first big image file directory.
A5. The Normative References section needs more than just TIFF 6.0. Section 3 cites only TIFF Revision 6.0 (1992). In production, almost every BigTIFF you encounter today depends on the TIFF 6.0 Technical Notes, particularly TN2 (revised JPEG-in-TIFF), because original-spec TIFF 6.0 JPEG was effectively withdrawn. Sentinel-2 L2A and Landsat Collection 2 are two examples where this matters. TN1 and TN3 are also widely implemented. Either add the Technical Notes as normative references where they apply, or note in §3 that the Technical Notes are the current operational baseline.
A6. Editorial pass needed. Some typos and article issues that should be cleaned up: "iniciative" (twice in §7.2, should be "initiative"), "WebAchive" (§7.2, "WebArchive" or "Internet Archive"), "contractic" (Permission 1 NOTE, "contradict"), "the the" (Permission 1), "a image file" (§1, "an image file"), "immediatelly" (§7.2). Minor individually; collectively they read as an unfinished draft.
B. Normative gaps
B1. Permission 2 doesn't say whether mixed widths are allowed within a file. It allows StripOffsets, StripByteCounts, TileOffsets, and TileByteCounts to use LONG8, while keeping LONG and SHORT valid. What it doesn't say is whether you can mix them within the same file or even within the same IFD. Can StripOffsets be LONG while StripByteCounts is LONG8? In libtiff this gets harmonised in practice, but the Standard should be explicit. My suggestion: paired offset/byte-count tags within a single IFD use the same width.
B2. §7.3 Table 1 leaves out IFD8. Table 1 ("Changes in data types") shows four mappings: Word→uint16, Unsigned long→uint32, Signed 8Byte→int64, Unsigned 8Byte→uint64. But the Standard actually introduces three new datatype tag values: 16=LONG8, 17=SLONG8, 18=IFD8. IFD8 is the new type that lets SubIFD chains use 64-bit offsets, and Table 1 doesn't mention it at all. Either expand Table 1 or split it into two: one for the terminology rebrand, one for the new datatype tag values. Cross-reference Table B.4.
B3. Version 43 has no evolution policy. Requirement 2 fixes the version number at 43 and the offset size at 8 bytes, with a parenthetical that "it could be 16 in a future version for SuperBig TIFFs." That hypothetical SuperBigTIFF would either need a new version number or it would fork the namespace. The Standard should pick one and say so. Reserving version 43 for 8-byte offsets and stating that any wider offset uses a new version number administered by OGC would be the simplest fix. OGC RAINBOW could host the registry.
B4. The conformance class only targets encoders. The TARGET TYPE in §A.1 is "BigTIFF Encoder." But Requirement 3.G is plainly about reader behaviour ("the reader SHALL check the type to verify that it contains an expected value"). Most BigTIFF software in the field is a reader (GDAL, libtiff, ImageMagick, the long tail of EO toolchains). Without a Reader Conformance Class, claims of "BigTIFF support" can't be tested. A reader class would cover type tolerance per Req 3.G, BIFD chain traversal, the inline-value-vs-offset disambiguation that IvanSanchez raised, graceful handling of trailing-zero next-BIFD pointers, and behaviour on malformed input.
B5. Req 3.F's byte-order rule needs to be explicit about the new uint64 fields. Requirement 3.F covers "multibyte values (e.g a SHORT, LONG, etc)." By inference this includes LONG8, SLONG8, IFD8, the BIFD entry count, the next-BIFD offset, and any inline LONG/LONG8 tag value. By literal reading it might not. A producer in a big-endian (MM) shop and a consumer in a little-endian (II) shop could read this differently. Tightening the requirement to say that the byte order indication governs every multi-byte field after the header would close the gap.
C. Security
C1. §IV says no security considerations have been made. That should not stand. I understand the document is a transcription of a 2004 specification and the original authors were not writing a 2026 Standard. But this is now a 2026 OGC Standard, and the empty Security Considerations clause is the first thing a procurement reviewer or government CIO will flag.
The threat model for BigTIFF parsers is well-documented and ugly:
- Integer overflow on the uint64 entry count multiplied by the 20-byte stride.
- Allocation denial-of-service via crafted oversized counts.
- Infinite loops through cyclic next-BIFD pointers (art1pirat's loop offsets question lands here).
- Offset values pointing into the header or beyond end-of-file.
- Resource exhaustion through deeply nested SubIFD chains, now wider with IFD8.
- Compression-bomb style attacks with Deflate, LZW, JPEG.
libtiff has had a steady stream of CVEs in exactly this territory over the past decade. CVE-2022-22844, CVE-2023-26965, and earlier ones going back to 2010. The Standard publishing in 2026 with no security guidance is a missed opportunity at best and a procurement liability at worst.
What I would suggest the clause cover, at minimum:
- Bounded-trust parsing: implementations should validate that entry_count × 20 does not exceed remaining file size before allocating BIFD storage.
- Cycle detection on next-BIFD chains and SubIFD/IFD8 references, with a recommended maximum depth.
- Offset bounds: every offset read from the file should be validated against [16, file_size) before it is dereferenced. Offsets pointing into the header are invalid.
- Tag-data overlap: implementations may detect overlapping ranges between distinct tags (this is one of art1pirat's points) and treat them as suspicious. They should not crash on them.
- Compression ratios: when TIFF compression is used, decompressed-data size should be bounded relative to compressed size by an implementation-defined ratio.
If draft text would help, I am happy to put a first cut together.
C2. IFD8 specifically needs traversal-depth guidance. Permission 2.B allows SubIFDs to use IFD8. This widens the inter-IFD reference graph from 32-bit to 64-bit. A maliciously crafted file can produce traversal graphs that are valid per the format but exhaust memory or stack. Real EO products rarely go beyond three or four levels of SubIFD nesting, so a recommended default of 16 levels and a recommended maximum of 65536 IFDs per file would not disrupt legitimate files and would give parser implementers a number to defend.
D. Geospatial and cloud-native interoperability
D1. The §9 media-type recommendation is fine for parsers but not for content negotiation. The Standard says BigTIFF should share image/tiff because software can programmatically distinguish them. That works for a parser. It doesn't work for HTTP content negotiation. A memory-constrained mobile or browser client may need to advertise that it cannot consume BigTIFF. A STAC asset declaration may need to differentiate. OGC API – Coverages clients may need to negotiate. A parameterised media type would solve this:
image/tiff; profile=bigtiff
or, where parameter conventions are not honoured:
image/tiff; profile="http://www.opengis.net/spec/BigTIFF/1.0"
This is closely related to fmigneault's RFC #6 on media types and could be addressed jointly.
D2. There is no cross-reference to Cloud Optimized GeoTIFF. COG (the candidate OGC Standard) explicitly depends on BigTIFF for files over 4 GiB, and both Standards live in the GeoTIFF SWG. BigTIFF doesn't reference COG, even informatively. Anyone reading BigTIFF in 2026 is most likely reading it because they are doing COG work. An informative note in §7 mentioning COG, plus a Bibliography entry, would make the linkage discoverable.
D3. BIFD placement matters for cloud-native readers. For rasters served from object storage and read via HTTP range requests, where the first BIFD sits relative to file start changes the latency you get. Put it at offset 16 (right after the header) and a range reader fetches metadata then pixel data in one or two round trips. Put it near end-of-file (perfectly legal under the Standard as written) and the reader pays an extra round trip for nothing. The Standard makes no recommendation either way. GDAL and rio-cogeo already do the right thing for COG. A non-normative recommendation in BigTIFF saying "for files intended for cloud-native streaming, the first BIFD should be placed near the beginning of the file, with overview-pyramid SubIFDs and BIFDs preceding pixel-data strips and tiles" would make the expectation explicit.
D4. ImageWidth and ImageLength should be allowed to be LONG8. Permission 2 covers Strip and Tile offset/byte-count tags. It doesn't cover the pixel-coordinate tags. Modern hyperspectral and SAR products from current-generation sensors regularly approach row or column counts where LONG (uint32) becomes uncomfortable. Req 3.G says readers should accept BYTE/SHORT/LONG/LONG8 for any unsigned integer field, which presumably covers this case, but encoders default to LONG and silently truncate when they shouldn't. An informative note that ImageWidth and ImageLength may be LONG8 in BigTIFF when row or column count exceeds 2³² would help.
D5. The ASCII datatype is 7-bit only, and that is a real problem. Datatype 2 (ASCII) is defined as 7-bit ASCII with NUL terminator, inherited from TIFF 6.0. In practice, EO products from India, China, the Arab world, Latin America, and Africa carry non-Latin metadata: place names in Devanagari, Telugu, Tamil, Mandarin, Arabic; instrument and collection names in original language. The common workaround today is to put UTF-8 bytes into ASCII slots without declaring it, which technically violates the spec. art1pirat raised UTF8 as a future-version idea. I would support that and add a concrete reason: every Indian-language place name in publicly released satellite rasters runs into this. Reserving a datatype value (19 = UTF8) in the BigTIFF namespace now, even without yet making it required, would prevent later contention.
D6. ML-generated rasters need a place to put provenance metadata. More and more rasters now are model outputs: segmentation masks, prediction surfaces, uncertainty layers. They need provenance: model identifier, model version, input-band specification, training-data hash, inference timestamp, confidence statistics. The TIFF private tag scheme accommodates this in principle, but there is no community convention and everyone reinvents their own. Not a defect in BigTIFF as written. Flag for future work, in coordination with TrainingDML-AI and the STAC ML-AOI extension.
E. Three things I would suggest as future work, not for this revision
E1. A BigTIFF Streaming Profile for resource-constrained readers. Some BigTIFF consumers cannot allocate arbitrary buffers: on-board satellite processors, edge devices doing real-time inference on EO imagery, browser-based viewers in WebAssembly. A streaming profile that constrains BIFD placement, entry count, and SubIFD depth to support bounded-memory parsing would help. We hit this directly in our orbital edge AI work, and the same constraints apply to several other platforms that exist or are coming.
E2. Integrity and immutability tags for MRV and audit workflows. Carbon MRV, regulatory disclosures (EU CSRD, India BRSR, voluntary carbon markets), and long-term scientific archival increasingly need cryptographic integrity proofs, per-tile or per-IFD hashes, and content-addressed identifiers. The TIFF tag space has no canonical home for these. Worth coordinating with GeoTIFF SWG and the OGC provenance work.
E3. DGGS interoperability. Discrete Global Grid Systems (H3, rHEALPix, S2, ISEA-based variants) are showing up everywhere in cloud-native EO right now as the indexing layer. Going from a BigTIFF tile grid to a DGGS cell structure is currently ad-hoc, and aligning the two reduces resampling loss and speeds up lookups. Worth a future work item with the DGGS SWG on a recommended convention for DGGS-aligned tile pyramids in BigTIFF/GeoTIFF.
That's the lot. C1 is the one I would push on hardest. The geospatial group is mostly about getting BigTIFF to land properly into the COG and STAC tooling that practitioners use day to day. The E group is flags, not asks.
Happy to follow up through GeoTIFF SWG or CSAPI SWG channels on any of these.
Narasimha Sharma Narayanam
Aganitha Space Technologies
9 May 2026
Public comment on candidate OGC BigTIFF Standard (OGC 21-061r1)
Submitted by: Narasimha Sharma Narayanam (@nsnarayanam)
Founder & CEO, Aganitha Space Technologies Pvt. Ltd
OGC CSAPI SWG · IEEE DMEW WG (voting member, GRSS Earth Observation Standards) · ISO/TC 211 · W3C WoT WG · IAF · FIET, ARAeS
Date: 9 May 2026
Document under review: OGC 21-061r1 (DRAFT)
Comment window closes: 24 May 2026
Comments below from someone who reads and writes BigTIFF rasters in production every working day. The same goal as the editor's: get the Van Damme / Eichhorn / libtiff work into OGC custody cleanly.
I have read through issue #5 and the points raised by IvanSanchez (units, offset reference frames, type disambiguation, the bits/bytes typo in A.1.1), art1pirat (offset definition, conformance edge cases, missing implementer guidance, UTF8 datatype), fmigneault (media types in RFC #6), and sub-issue #7. None of those are repeated below. What follows is new ground, plus a few defects in the PDF I haven't seen flagged anywhere.
Grouped loosely by type, not by priority. If only one of these gets read, please make it C1 (security).
A. Things in the document that look like template residue or factual errors
A1. The cover-page dates are placeholders. The cover lists Submission, Approval, and Publication Dates all as 2029-03-30. Annex C, the Revision History, has a single row: "2016-04-28, 0.1, G. Editor, all, initial version." Both look like template carryover from the AsciiDoc source. They will need real dates and a real history before approval. The 2021 Testbed-17 origin and the 2024–2026 SWG transitions probably belong in the history table.
A2. Annex A is labelled both informative and normative. The Annex A title page reads "CONFORMANCE CLASS ABSTRACT TEST SUITE (NORMATIVE)" but the heading immediately below says "ANNEX A (INFORMATIVE)" with "(NORMATIVE)" appended. Clause 2 (Conformance) clearly intends the abstract test suite to be normative, so the "(INFORMATIVE)" label needs to come out of the Annex A heading.
A3. Table 4 has a typo in the OFFSET column. Requirement 3, Table 4 (BigTIFF Tag structure) lists the byte offsets as 0, 1, 2, 4, 12. The first field (Tag identifying code) is uint16 and takes 2 bytes, so the second field should start at offset 2, not offset 1. The stray "1" looks like a footnote marker that has slipped into the offset column. Annex B Table B.3, which has the equivalent classic-TIFF layout, is correctly laid out and is a useful reference.
A4. Definitions §4.1 and §4.2 are circular. Both read "a modified data structure" without saying what is modified. A reader who comes to BigTIFF without knowing classic TIFF cannot get the distinguishing feature from these definitions. Suggested replacements:
A5. The Normative References section needs more than just TIFF 6.0. Section 3 cites only TIFF Revision 6.0 (1992). In production, almost every BigTIFF you encounter today depends on the TIFF 6.0 Technical Notes, particularly TN2 (revised JPEG-in-TIFF), because original-spec TIFF 6.0 JPEG was effectively withdrawn. Sentinel-2 L2A and Landsat Collection 2 are two examples where this matters. TN1 and TN3 are also widely implemented. Either add the Technical Notes as normative references where they apply, or note in §3 that the Technical Notes are the current operational baseline.
A6. Editorial pass needed. Some typos and article issues that should be cleaned up: "iniciative" (twice in §7.2, should be "initiative"), "WebAchive" (§7.2, "WebArchive" or "Internet Archive"), "contractic" (Permission 1 NOTE, "contradict"), "the the" (Permission 1), "a image file" (§1, "an image file"), "immediatelly" (§7.2). Minor individually; collectively they read as an unfinished draft.
B. Normative gaps
B1. Permission 2 doesn't say whether mixed widths are allowed within a file. It allows StripOffsets, StripByteCounts, TileOffsets, and TileByteCounts to use LONG8, while keeping LONG and SHORT valid. What it doesn't say is whether you can mix them within the same file or even within the same IFD. Can StripOffsets be LONG while StripByteCounts is LONG8? In libtiff this gets harmonised in practice, but the Standard should be explicit. My suggestion: paired offset/byte-count tags within a single IFD use the same width.
B2. §7.3 Table 1 leaves out IFD8. Table 1 ("Changes in data types") shows four mappings: Word→uint16, Unsigned long→uint32, Signed 8Byte→int64, Unsigned 8Byte→uint64. But the Standard actually introduces three new datatype tag values: 16=LONG8, 17=SLONG8, 18=IFD8. IFD8 is the new type that lets SubIFD chains use 64-bit offsets, and Table 1 doesn't mention it at all. Either expand Table 1 or split it into two: one for the terminology rebrand, one for the new datatype tag values. Cross-reference Table B.4.
B3. Version 43 has no evolution policy. Requirement 2 fixes the version number at 43 and the offset size at 8 bytes, with a parenthetical that "it could be 16 in a future version for SuperBig TIFFs." That hypothetical SuperBigTIFF would either need a new version number or it would fork the namespace. The Standard should pick one and say so. Reserving version 43 for 8-byte offsets and stating that any wider offset uses a new version number administered by OGC would be the simplest fix. OGC RAINBOW could host the registry.
B4. The conformance class only targets encoders. The TARGET TYPE in §A.1 is "BigTIFF Encoder." But Requirement 3.G is plainly about reader behaviour ("the reader SHALL check the type to verify that it contains an expected value"). Most BigTIFF software in the field is a reader (GDAL, libtiff, ImageMagick, the long tail of EO toolchains). Without a Reader Conformance Class, claims of "BigTIFF support" can't be tested. A reader class would cover type tolerance per Req 3.G, BIFD chain traversal, the inline-value-vs-offset disambiguation that IvanSanchez raised, graceful handling of trailing-zero next-BIFD pointers, and behaviour on malformed input.
B5. Req 3.F's byte-order rule needs to be explicit about the new uint64 fields. Requirement 3.F covers "multibyte values (e.g a SHORT, LONG, etc)." By inference this includes LONG8, SLONG8, IFD8, the BIFD entry count, the next-BIFD offset, and any inline LONG/LONG8 tag value. By literal reading it might not. A producer in a big-endian (MM) shop and a consumer in a little-endian (II) shop could read this differently. Tightening the requirement to say that the byte order indication governs every multi-byte field after the header would close the gap.
C. Security
C1. §IV says no security considerations have been made. That should not stand. I understand the document is a transcription of a 2004 specification and the original authors were not writing a 2026 Standard. But this is now a 2026 OGC Standard, and the empty Security Considerations clause is the first thing a procurement reviewer or government CIO will flag.
The threat model for BigTIFF parsers is well-documented and ugly:
libtiff has had a steady stream of CVEs in exactly this territory over the past decade. CVE-2022-22844, CVE-2023-26965, and earlier ones going back to 2010. The Standard publishing in 2026 with no security guidance is a missed opportunity at best and a procurement liability at worst.
What I would suggest the clause cover, at minimum:
If draft text would help, I am happy to put a first cut together.
C2. IFD8 specifically needs traversal-depth guidance. Permission 2.B allows SubIFDs to use IFD8. This widens the inter-IFD reference graph from 32-bit to 64-bit. A maliciously crafted file can produce traversal graphs that are valid per the format but exhaust memory or stack. Real EO products rarely go beyond three or four levels of SubIFD nesting, so a recommended default of 16 levels and a recommended maximum of 65536 IFDs per file would not disrupt legitimate files and would give parser implementers a number to defend.
D. Geospatial and cloud-native interoperability
D1. The §9 media-type recommendation is fine for parsers but not for content negotiation. The Standard says BigTIFF should share
image/tiffbecause software can programmatically distinguish them. That works for a parser. It doesn't work for HTTP content negotiation. A memory-constrained mobile or browser client may need to advertise that it cannot consume BigTIFF. A STAC asset declaration may need to differentiate. OGC API – Coverages clients may need to negotiate. A parameterised media type would solve this:This is closely related to fmigneault's RFC #6 on media types and could be addressed jointly.
D2. There is no cross-reference to Cloud Optimized GeoTIFF. COG (the candidate OGC Standard) explicitly depends on BigTIFF for files over 4 GiB, and both Standards live in the GeoTIFF SWG. BigTIFF doesn't reference COG, even informatively. Anyone reading BigTIFF in 2026 is most likely reading it because they are doing COG work. An informative note in §7 mentioning COG, plus a Bibliography entry, would make the linkage discoverable.
D3. BIFD placement matters for cloud-native readers. For rasters served from object storage and read via HTTP range requests, where the first BIFD sits relative to file start changes the latency you get. Put it at offset 16 (right after the header) and a range reader fetches metadata then pixel data in one or two round trips. Put it near end-of-file (perfectly legal under the Standard as written) and the reader pays an extra round trip for nothing. The Standard makes no recommendation either way. GDAL and rio-cogeo already do the right thing for COG. A non-normative recommendation in BigTIFF saying "for files intended for cloud-native streaming, the first BIFD should be placed near the beginning of the file, with overview-pyramid SubIFDs and BIFDs preceding pixel-data strips and tiles" would make the expectation explicit.
D4. ImageWidth and ImageLength should be allowed to be LONG8. Permission 2 covers Strip and Tile offset/byte-count tags. It doesn't cover the pixel-coordinate tags. Modern hyperspectral and SAR products from current-generation sensors regularly approach row or column counts where LONG (uint32) becomes uncomfortable. Req 3.G says readers should accept BYTE/SHORT/LONG/LONG8 for any unsigned integer field, which presumably covers this case, but encoders default to LONG and silently truncate when they shouldn't. An informative note that ImageWidth and ImageLength may be LONG8 in BigTIFF when row or column count exceeds 2³² would help.
D5. The ASCII datatype is 7-bit only, and that is a real problem. Datatype 2 (ASCII) is defined as 7-bit ASCII with NUL terminator, inherited from TIFF 6.0. In practice, EO products from India, China, the Arab world, Latin America, and Africa carry non-Latin metadata: place names in Devanagari, Telugu, Tamil, Mandarin, Arabic; instrument and collection names in original language. The common workaround today is to put UTF-8 bytes into ASCII slots without declaring it, which technically violates the spec. art1pirat raised UTF8 as a future-version idea. I would support that and add a concrete reason: every Indian-language place name in publicly released satellite rasters runs into this. Reserving a datatype value (19 = UTF8) in the BigTIFF namespace now, even without yet making it required, would prevent later contention.
D6. ML-generated rasters need a place to put provenance metadata. More and more rasters now are model outputs: segmentation masks, prediction surfaces, uncertainty layers. They need provenance: model identifier, model version, input-band specification, training-data hash, inference timestamp, confidence statistics. The TIFF private tag scheme accommodates this in principle, but there is no community convention and everyone reinvents their own. Not a defect in BigTIFF as written. Flag for future work, in coordination with TrainingDML-AI and the STAC ML-AOI extension.
E. Three things I would suggest as future work, not for this revision
E1. A BigTIFF Streaming Profile for resource-constrained readers. Some BigTIFF consumers cannot allocate arbitrary buffers: on-board satellite processors, edge devices doing real-time inference on EO imagery, browser-based viewers in WebAssembly. A streaming profile that constrains BIFD placement, entry count, and SubIFD depth to support bounded-memory parsing would help. We hit this directly in our orbital edge AI work, and the same constraints apply to several other platforms that exist or are coming.
E2. Integrity and immutability tags for MRV and audit workflows. Carbon MRV, regulatory disclosures (EU CSRD, India BRSR, voluntary carbon markets), and long-term scientific archival increasingly need cryptographic integrity proofs, per-tile or per-IFD hashes, and content-addressed identifiers. The TIFF tag space has no canonical home for these. Worth coordinating with GeoTIFF SWG and the OGC provenance work.
E3. DGGS interoperability. Discrete Global Grid Systems (H3, rHEALPix, S2, ISEA-based variants) are showing up everywhere in cloud-native EO right now as the indexing layer. Going from a BigTIFF tile grid to a DGGS cell structure is currently ad-hoc, and aligning the two reduces resampling loss and speeds up lookups. Worth a future work item with the DGGS SWG on a recommended convention for DGGS-aligned tile pyramids in BigTIFF/GeoTIFF.
That's the lot. C1 is the one I would push on hardest. The geospatial group is mostly about getting BigTIFF to land properly into the COG and STAC tooling that practitioners use day to day. The E group is flags, not asks.
Happy to follow up through GeoTIFF SWG or CSAPI SWG channels on any of these.
Narasimha Sharma Narayanam
Aganitha Space Technologies
9 May 2026