[OSGeo-Standards] Comments on OGC 12-101 " OGC® Web Coverage Service 2.0 Interface Standard - GeoTIFF Coverage Encoding Extension"
Mr. Puneet Kishor
punk.kish at gmail.com
Wed Oct 31 17:39:30 PDT 2012
Gosh, this is *really* well done. I learned a lot just from reading the comments. Much respect Even.
On Nov 1, 2012, at 7:29 AM, Even Rouault <even.rouault at mines-paris.org> wrote:
> 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