[OSGeo-Standards] Comments on OGC 12-101 " OGC® Web Coverage Service 2.0 Interface Standard - GeoTIFF Coverage Encoding Extension"
Carl Reed
creed at opengeospatial.org
Wed Oct 31 16:35:00 PDT 2012
Even -
Thank you for providing these excellent and detailed comments.
Much appreciated
Regards
Carl
-----Original Message-----
From: Even Rouault
Sent: Wednesday, October 31, 2012 5:29 PM
To: standards at lists.osgeo.org ; requests at lists.opengeospatial.org
Subject: [OSGeo-Standards] Comments on OGC 12-101 " OGC® Web Coverage
Service 2.0 Interface Standard - GeoTIFF Coverage Encoding Extension"
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
_______________________________________________
Standards mailing list
Standards at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/standards
More information about the Standards
mailing list