GeoTIFF and BigTIFF

[rouault]

The current version of the standard explicitly points to TIFF 6.0 as the file structure on which GeoTIFF builds on. But since then the BigTIFF format as been developped as an extension of TIFF 6.0 (implemented in particular since libtiff 4.0), and the GeoTIFF tags & keys are perfectly compatible of BigTIFF, so there's no strong reason to exclude a "GeoBigTIFF". One difficulty from a formal point of view is that BigTIFF is less standardized than TIFF, but https://www.awaresystems.be/imaging/tiff/bigtiff.html is a decent specification of it that could probably be refered to

[EmDevys]

(message transferred by @rouault on 12 March 2021) Sujet : | Re: [Tiff] [Off Topic] TIFF and multispectral images of historical documents? Date : | Fri, 12 Mar 2021 18:32:11 +0000 De : | Leonard Rosenthol via Tiff tiff@lists.osgeo.org Répondre à : | Leonard Rosenthol lrosenth@adobe.com Pour : | Andrew Brooks arb@sat.dundee.ac.uk, tiff@lists.osgeo.org tiff@lists.osgeo.org

Sorry about the delay – lawyers are not always the easiest folks to get responses from… Adobe Legal has decided that TIFF is not a trademark that we wish to defend. Please feel free to continue to use it as you already have been. Leonard

From: Tiff tiff-bounces@lists.osgeo.org on behalf of Andrew Brooks arb@sat.dundee.ac.uk Date: Tuesday, March 2, 2021 at 12:38 PM To: "tiff@lists.osgeo.org" tiff@lists.osgeo.org Subject: Re: [Tiff] [Off Topic] TIFF and multispectral images of historical documents?

If Adobe were serious about defending their trademark they would have to demonstrate that they engage with people who wish to use it. The lack of engagement which they have demonstrated so far suggests they have abandoned their claims to TIFF.

On Tue, 2 Mar 2021 at 14:46, Roger Leigh rleigh@codelibre.net wrote: On 2 Mar 2021, at 12:20, Leonard Rosenthol via Tiff tiff@lists.osgeo.org wrote:

It should also be noted that the OME-TIFF people are in violation of Adobe’s Trademark on the use of TIFF, so I personally wouldn’t bet on a horse that hadn’t gotten its licenses in order…

While I no longer work for the OME organisation myself, I would be interested to know what exactly would be wrong with the licensing here. I can always pass along any concerns you have to the people I know who are working there. OME-TIFF is not a trademark or as far as I’m aware infringing on the TIFF trademark. The actual code, both Java and C++ implementations, are BSD-licenced and freely available, as is the open specification.

OME-TIFF is just a plain baseline TIFF or BigTIFF with an XML metadata block in the ImageDescription. The name just means “OME” metadata model inside a “TIFF” container, to differentiate it from the original OME-XML which was OME metadata serialised entirely as XML. Future variants might be for example OME-HDF5 or OME-Zarr. The “-TIFF” suffix is a purely functional description of a TIFF-based file format. Why is that problematic?

Regards, Roger

---

Tiff mailing list Tiff@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/tiff

[EmDevys]

after the OGC TC meeting on 15 June 2021, there were some discussion to add support to bigTIFF (in addition to TIFF) in OGC GeoTIFF 1.2. There is a need to include a reference to the bigTIFF specification, and to modify requirement 1.1 in order to allow bigTIFF in addition to plain TIFF. Apparently no other impact onGeoTIFF specification, but to be confirmed.

[cmheazel]

@EmDevys GeoTIFF 1.1 defines the data types (short, integer, double) for a 32 bit architecture (short = 2 bytes, double = 8). Is a short still 2 bytes in BigTIFF? Or is it 4 bytes which a 64 bit architecture would imply.

[rouault]

is a short still 2 bytes in BigTIFF?

yes. The existing types of Classic TIFF don't change. BigTIFF adds 3 types for 64-bit integers. See "Other miscellaneous details" paragraph at https://www.awaresystems.be/imaging/tiff/bigtiff.html

[cmheazel]

@EmDevys Some of the tests in the ATS specify the values of individual bytes, assuming a 32 bit space. The continued validity of these tests will also have to be checked.

[EmDevys]

For the 3 added types for bigTIFF, we have probably to incorporate them in the spec. presumably in Req. 1.3 about the TIFF 6.0 tag data-types

[EmDevys]

@cmheazel about ETS, the OGC GeotIFF 1.1 includes in Annexe A: A.2.1. TIFF Core Test Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/Core

Requirements: http://www.opengis.net/spec/GeoTIFF/1.1/req/TIFF http://www.opengis.net/spec/GeoTIFF/1.1/req/ByteOrder http://www.opengis.net/spec/GeoTIFF/1.1/req/DataTypes

The TIFF data types are to be extended, and subsequently the ETS must be extended as well

[rouault]

For the 3 added types for bigTIFF, we have probably to incorporate them in the spec. presumably in Req. 1.3 about the TIFF 6.0 tag data-types

That's not necessary. Req 1.3 references ASCII, SHORT and the IEEE double-precision floating point "DOUBLE" types because we need them for the GeoTIFF TIFF tags and Geokeys. We don't need 64-bit integer data types for the GeoTIFF payload. I believe only http://www.opengis.net/spec/GeoTIFF/1.1/req/TIFF and Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/Core should be modified. Agreed that the ETS will need extension.

[cmheazel]

TIFF conformance is it's own Requirements Class. So I see two possibilities: 1) Add a BigTIFF Requirements Class. 2) Extend the TIFF Requirements Class to include BigTIFF

Option 1 would require the most effort. So I suggest we assume option 1 for planning purposes. But our ideal should be option 2.

[EmDevys]

@rouault I agree, I double-checked, and GeoTIFF GeoKeys don't need any 64-bit integer data type. @cmheazel I would be in favor of option 2, as we don't use bigTIFF in the GeoKeys, only the TIFF raster (and indexing mechanism) may use it. And it seems the reference opensource component in support of tiff is also supporting bigTIFF, there is no dedidated libBigTIFF.

[joanma747]

In the testbet17 a draft document of a BigTIFF community standard has been started: https://gitlab.ogc.org/ogc/T17-D046-COG-Specification-ER/-/tree/master/standardDrafts/BigTIFF. My suggestion would be to take this as a new working item for this group and then make GeoTIFF 1.2 (or 2.0) dependent of it.

[joanma747]

We keep this issue open until GeoTIFF is referencing BigTIFF as part of the Req 1