JERR_BAD_HUFF_TABLE

[vindicatorr]

I have a few tiff images from around the XP era.

I noticed the images can't be read now with anything. I've spun up ME, XP, 7 virtual machines to try using anything around that time, and they all showed black or errored.

In linux, the latest libtiff/jpeg (including your port) all return "Bogus Huffman table definition" or "Huffman table too big", depending on the version.

PrintDirectory returns:

TIFF Directory at offset 0x8 (8)
  Subfile Type: (0 = 0x00000000)
  Image Width: 1380 Image Length: 1964
  Resolution: 800, 800 pixels/inch
  Bits/Sample: 8
  Compression Scheme: Old-style JPEG
  Photometric Interpretation: YCbCr
  FillOrder: msb-to-lsb
  YCbCr Subsampling: 4, 1
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 3
  Rows/Strip: 8
  Planar Configuration: single image plane
  Tag 11: 
  Software: 
  DateTime: 
  Tag 32934: 
  RichTIFFIPTC Data: <present>, 60 bytes
  EXIFIFDOffset: 
  Tag 50971: 
  JpegInterchangeFormat: 2610
  JpegInterchangeFormatLength: 601
  JpegQTables: 777 846 846
  JpegDcTables: 934 1150 1150
  JpegAcTables: 967 1183 1183
  JpegProc: 1
  JpegRestartInterval: 0

tiffdump returns:

Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 8 (0x8) next 0 (0)
11 (0xb) ASCII (2) 14<digiKam-4.7.0\0>
SubFileType (254) LONG (4) 1<0>
ImageWidth (256) SHORT (3) 1<1380>
ImageLength (257) SHORT (3) 1<1964>
BitsPerSample (258) SHORT (3) 3<8 8 8>
Compression (259) SHORT (3) 1<6>
Photometric (262) SHORT (3) 1<6>
FillOrder (266) SHORT (3) 1<1>
StripOffsets (273) LONG (4) 246<<246 entries here>>
Orientation (274) SHORT (3) 1<1>
SamplesPerPixel (277) SHORT (3) 1<3>
RowsPerStrip (278) SHORT (3) 1<8>
StripByteCounts (279) LONG (4) 246<<246 entries here>>
XResolution (282) RATIONAL (5) 1<800>
YResolution (283) RATIONAL (5) 1<800>
ResolutionUnit (296) SHORT (3) 1<2>
Software (305) ASCII (2) 58<Oi/GFS, writer v00.06.00P, (c) Wang Labs, Inc. 1990, 1991\0>
DateTime (306) ASCII (2) 20<2004:01:03 02:12:47\0>
JPEGProcessingMode (512) SHORT (3) 1<1>
JPEGInterchangeFormat (513) LONG (4) 1<2610>
JPEGInterchangeFormatLength (514) LONG (4) 1<601>
JPEGRestartInterval (515) SHORT (3) 1<0>
JPEGQTables (519) LONG (4) 3<777 846 846>
JPEGDCTables (520) LONG (4) 3<934 1150 1150>
JPEGACTables (521) LONG (4) 3<967 1183 1183>
YCbCrSubsampling (530) SHORT (3) 2<1 4>
32934 (0x80a6) LONG (4) 1<0>
33723 (0x83bb) LONG (4) 15<<15 entries here>>
34665 (0x8769) LONG (4) 1<2572>
50971 (0xc71b) ASCII (2) 20<2004:01:03 02:12:47\0>

We can see software made by Wang Labs was used. The 2004 date shows I used some software with it at that time (would have been in Vista). The Digikam 4.7 shows that I used it with the images in 2015 (would have been in Ubuntu, when I started my transition to linux). I'm pretty sure I originally had them as lossless LZW, but at some point needed space and saw another compression option which I used (now seeing it was ojpeg).

Stepping through the libtiff code for tiff2rgba, it fails with those error messages at the JPEGACTables tag.

According to https://www.awaresystems.be/imaging/tiff/tifftags/jpeginterchangeformat.html those *Tables can be pointing to wrong locations.

Can you tell if anything looks off with what I've provided? Do you think just dumping the information from JPEGInterchangeFormat (using JPEGInterchangeFormatLength) to a file would be all I need to get the jpeg image?

[vindicatorr]

Given that the library fails when checking the DC/ACTables, it was no surprise to me when I came across (in TIFFTechNote2):

Minimum requirements for TIFF/JPEG
...
Use the ISO baseline JPEG process: 8-bit data precision, Huffman coding, with no more than 2 DC and 2 AC Huffman tables.

Seeing the last entry for each table being a duplicate of the previous value, is making me think(/hope?) that the problem is as simple as that.

I'm not sure if I could get away with just setting the Directory Field "Number of values" part to 2 instead of 3 and shift the rest of the data back to fill in the void.

I'm curious if anyone has a tiff using compression-6 that IS viable (image can be viewed) and only shows 2 entries for each table.

Looking at tif_ojpeg.c, I wonder why if (v32 > NUM_HUFF_TBLS), where NUM_HUFF_TBLS is defined as 4, is set up that way when each tag is processed separately. I'd think it'd need to be set to 2.