[OSGeo-Standards] Comments on OGC 12-101 " OGC® Web Coverage Service 2.0 Interface Standard - GeoTIFF Coverage Encoding Extension"

Even Rouault even.rouault at mines-paris.org
Wed Oct 31 16:29:21 PDT 2012 

PART A

1. Evaluator:
        Even Rouault (even dot rouault at mines-paris dot org),
        GDAL/OGR contributor

2. Submission:
    OGC 12-101, "OGC® Web Coverage Service 2.0 Interface Standard - GeoTIFF 
Coverage Encoding Extension"

-----------------------------------------------------

PART B

1. Requirement: #6, "compression" (/req/geotiff-coverage/additional-parameters)

2. Implementation Specification Section number: §6.3.1 GetCoverage request

3. Criticality: Major

4. Comments/justifications for changes:

There are some ambiguities that should be clarified to ensure proper 
understanding and interoperability related on "compression". It is not always 
obvious to correlate the string values of the proposed standard with the 
actual values of the related TIFF compression tag (259). More precisely, :

	* "Huffman" is not the usual way of designating the "Modified Huffman 
Compression" (TIFF compression scheme) of the TIFF6 specification. Even the 
TIFF specification isn't completely consistant in the naming, since this method 
is also called "CCITT 1D" in "Appendix A: TIFF Tags Sorted by Number". In GDAL 
or in libtiff software, it is for example called CCITTRLE. I'm not sure if 
there's an universally agreed way of designating this method, but some 
clarification might be helpfull.

	* "JPEG". There is a high risk of confusion on this one. In TIFF6 
specification, there's a JPEG compression method described, as being the 
compression method number 6. However, this method is only of historical 
revelance, and is now known as the "Old JPEG" in TIFF specification. 
http://www.remotesensing.org/libtiff/TIFFTechNote2.html (which has been mostly 
pasted into 
http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf ) explains 
the problems with this original specification, and an alternative method, 
number 7. Producers of JPEG compressed TIFF are highly encouraged to produce 
files using method number 7, and deprecate method 6. This is COMPRESSION_JPEG = 
7 constant of libtiff, and the COMPRESS=JPEG creation option of the GDAL 
GeoTIFF driver.

Related to JPEG compression, the proposed standard doesn't specify which value 
for the Photometric tag the server should use to generate the GeoTIFF. For 3 
bands RGB JPEG-in-TIFF, PhotometricInterpretation = YCbCr or RGB can be used. 
YCbCr leads to higher compression rates (at the expense of some quality loss) 
due to the default subsampling factor of 2 for the Cb and Cr componants. Not 
specifying the photometric interpreation to use (or not offering a parameter to 
the user to specify it) isn't strictly required for this standard to be 
implemented successfully : this lets an implementation choice to the server 
side, and the client side must be able to cope with YCbCr or RGB photometric 
interpretations.

       * "DEFLATE". This method isn't described at all in TIFF6 specification, 
but in http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf as 
compression = 8. In libtiff, this corresponds to the following constant : 
COMPRESSION_ADOBE_DEFLATE = 8. Note that libtiff also defines 
COMPRESSION_DEFLATE = 32946, but this is apparently only historical. In GDAL, 
COMPRESS=DEFLATE actually maps to libtiff COMPRESSION_ADOBE_DEFLATE = 8


--> Recommandation 1 : add a mapping between the string in the GML and the 
value of the Compression TIFF tag, like the following table :

	Compression name			Value of Compression TIFF tag
---------------------------------------------------------------------------------------------------------------
	None						1
	PackBits					32773
	Huffman					2
	LZW						5
	JPEG						7 (as in TIFFTechNote2)
	DEFLATE					8
	
--> Recommandation 2 : make it clear that the JPEG in the GeoTIFF Coverage 
Encoding Extension is meant to be the method 7 as in TIFFTechNote 2, inseadd 
of method 6 as in TIFF6.pdf

--> Recommandation 3 : add mention to TIFFTechNote2 and TIFFphotoshop.pdf in 
Bibliography

-----------------------------------------------------

PART B

1. Requirement: #6, "predictor" (/req/geotiff-coverage/additional-parameters)

2. Implementation Specification Section number: §6.3.1 GetCoverage request

3. Criticality: Minor

4. Comments/justifications for changes:

a) It should perhaps be mentionned that "predictor" only makes sense for LZW 
and Deflate compression methods of the proposed standard (references:  
TIFFPhotoshop.pdf page 2, 
http://www.awaresystems.be/imaging/tiff/tifftags/predictor.html ). The later 
page mentions that "Theoretically, the predictor step is independent from the 
compression step, and thus can be combined with any compression scheme", but 
in practice a review of the libtiff code only that is only handled by the 
Deflate, LZW, Pixarlog and LZMA compression methods. I have no strong opinion 
on whether it should be mentionned in an informational note that the 
applicability of predictor is limited to LZW and Deflate , or if this should be 
formalized as a constraint (like jpeg_quality only applicate for 
compression=jpeg).

b) As far as "Floatingpoint" is concerned, this method isn't described in 
TIFF6.pdf. http://www.awaresystems.be/imaging/tiff/tifftags/predictor.html 
mentions that "A third specification supplement from Adobe, that is not yet 
available on-line, defines this new value:  3 = Floating point horizontal 
differencing. ". Actually, I found in 
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf 
a mention to "3 = Floating Point. Documented in “Adobe Photoshop TIFF 
Technical Note 3” (page 20) and links to http://chriscox.org/TIFFTN3d1.pdf 
"Adobe Photoshop® TIFF Technical Note 3" . This method is implemented in 
libtiff.

-----------------------------------------------------

PART B

1. Requirement: #6 (/req/geotiff-coverage/additional-parameters)

2. Implementation Specification Section number: §6.3.1 GetCoverage request

3. Criticality: Minor

4. Comments/justifications for changes:

There's no apparent consistency rule for the case of the values of the various 
parameters.
- For compression, you have : "None", "PackBits", "Huffman", "LZW", "JPEG", 
"DEFLATE” (mix of UpperCamelCase and upper case).
- For predictor, you have : "None", "Horizontal", "Floatingpoint" (why not 
FloatingPoint ?).
- For interleave, you have "pixel", "band" (lower case)

-----------------------------------------------------

PART B

1. Requirement: #6, "tilewidth" and "tileheight" (/req/geotiff-
coverage/additional-parameters)

2. Implementation Specification Section number: §6.3.1 GetCoverage request

3. Criticality: Minor

4. Comments/justifications for changes:

Perhaps add a note for implementators of the server side that some 
care/validation should be made with large values of those parameters. It is 
possible to generate a 20x20 raster, with for example 65536x65536 tile 
dimensions. This can lead to huge RAM, CPU and temporary storage consumption.

-----------------------------------------------------

PART B

1. Requirement: 

2. Implementation Specification Section number: Documentation of 
"predictorType" in wcsGeotiff.xsd

3. Criticality: Minor

4. Comments/justifications for changes:

The current documentation predictorType is a copy&paste error from the 
documentation of interleaveType

-----------------------------------------------------

PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Minor

4. Comments/justifications for changes:

The proposed standard only refers to "classical" TIFF, which is limited to 
files smaller than 4GB. Has it been considered that BigTIFF 
(http://www.remotesensing.org/libtiff/bigtiffpr.html) could be necessary to 
satisfy some huge requests ? I'm not sure however if this is in the scope of 
WCS to address such requests.

-----------------------------------------------------


PART B

1. Requirement: 

2. Implementation Specification Section number: Annex B Bibliography

3. Criticality: Major

4. Comments/justifications for changes:

Add a link to :
- http://www.remotesensing.org/libtiff/TIFFTechNote2.html : for JPEG 
compression (method 7)
- http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf : for 
Deflate compression (method 8)
- http://chriscox.org/TIFFTN3d1.pdf : for Floating-point predictor algorithm

More information about the Standards mailing list