Closed Pomax closed 1 month ago
If it's DEFLATE, it should not be too difficult to add support for it. The reason it's not implemented is that this kind of compression is not described in the TIFF specification and we never got an image with it. I'll have to find where the format is extended with DEFLATE.
The reason it's not implemented is that this kind of compression is not described in the TIFF specification and we never got an image with it
That's fair. Hopefully the attached image helps.
It helped, thanks!
maybe useful here just in case a few more are missing: https://web.archive.org/web/20240329145331/https://www.awaresystems.be/imaging/tiff/tifftags/compression.html lists a bunch more "unusual" numbers:
IFD | Image |
---|---|
Code | 259 (hex 0x0103) |
Name | Compression |
LibTiff name | TIFFTAG_COMPRESSION |
Type | SHORT |
Count | 1 |
Default | 1 (No compression) |
Compression scheme used on the image data.
The specification defines these values to be baseline:
1 = No compression 2 = CCITT modified Huffman RLE 32773 = PackBits compression, aka Macintosh RLE
Additionally, the specification defines these values as part of the TIFF extensions:
3 = CCITT Group 3 fax encoding 4 = CCITT Group 4 fax encoding 5 = LZW 6 = JPEG ('old-style' JPEG, later overridden in Technote2)
Technote2 overrides old-style JPEG compression, and defines:
7 = JPEG ('new-style' JPEG)
Adobe later added the deflate compression scheme:
8 = Deflate ('Adobe-style')
The TIFF-F specification (RFC 2301) defines:
9 = Defined by TIFF-F and TIFF-FX standard (RFC 2301) as ITU-T Rec. T.82 coding, using ITU-T Rec. T.85 (which boils down to JBIG on black and white). 10 = Defined by TIFF-F and TIFF-FX standard (RFC 2301) as ITU-T Rec. T.82 coding, using ITU-T Rec. T.43 (which boils down to JBIG on color).
LibTiff supports most of these. (Even though it can be argued that old-style JPEG cannot be really properly supported, and is probably best ignored, there is some attempt at decoding support for some common old-style JPEG interpretations.) Additionally, LibTiff adds support for some compression schemes that are not part of the specification and are somewhat less common. Here's LibTiff's definition of possible values:
COMPRESSION_NONE = 1; COMPRESSION_CCITTRLE = 2; COMPRESSION_CCITTFAX3 = COMPRESSION_CCITT_T4 = 3; COMPRESSION_CCITTFAX4 = COMPRESSION_CCITT_T6 = 4; COMPRESSION_LZW = 5; COMPRESSION_OJPEG = 6; COMPRESSION_JPEG = 7; COMPRESSION_NEXT = 32766; COMPRESSION_CCITTRLEW = 32771; COMPRESSION_PACKBITS = 32773; COMPRESSION_THUNDERSCAN = 32809; COMPRESSION_IT8CTPAD = 32895; COMPRESSION_IT8LW = 32896; COMPRESSION_IT8MP = 32897; COMPRESSION_IT8BL = 32898; COMPRESSION_PIXARFILM = 32908; COMPRESSION_PIXARLOG = 32909; COMPRESSION_DEFLATE = 32946; COMPRESSION_ADOBE_DEFLATE = 8; COMPRESSION_DCS = 32947; COMPRESSION_JBIG = 34661; COMPRESSION_SGILOG = 34676; COMPRESSION_SGILOG24 = 34677; COMPRESSION_JP2000 = 34712;
The DNG specification specifies that while Compression value 7 (JPEG) combined with a PhotometricInterpretation value 6 (YCbCr) or 1 (BlackIsZero) and a uniform BitsPerSample value of 8 indicates normal baseline JPEG compression, the same Compression value 7 (JPEG) combined with another PhotometricInterpretation value and/or another BitsPerSample value is also possible and should always indicate lossless JPEG compression (lossless sequential Huffman, SOF3).
A later version of the DNG specification allows for the combination of Photometric value 34892 (LinearRaw) and uniform BitsPersample value 8, and either lossless or lossy JPEG compression. Taking care not to contradict the previous rule mentioned earlier, Compression value 7 should indicate lossless JPEG, and a new Compression value was required to indication lossy JPEG. The newly defined Compression value is 34892.
34892 = Lossy JPEG (should only be combined with Photometric value 34892 (LinearRaw) and uniform BitsPersample value 8, indicates lossy JPEG where Compression value 7 with these Photometric and BitsPerSample values would indicate lossless JPEG).
We recommend DNG writers follow this specification. DNG readers can treat Compression values 7 and 34892 along the same path, and use the actual JPEG markers in the compressed data to set up a correct decoding chain. Any robust and liberal TIFF decoder, and not just DNG decoder, should probably be doing that anyway.
I ran a Lightroom TIFF through irfanview to make sure all the Adobe-specific BS got thrown away (turning it from 76MB into a 15MB tiff), but trying to load the result using
tiff
results in the title's error.TIFF file in question (zipped): frame-00001 - Copy.zip
As far as I can tell, this is just a plain old DEFLATE encoding so... why would this error out?