2016.09.19 18:47 "Re: [Tiff] Accuracy of TIFF Field metadata (COLORMAP)", by

I recently discovered a problem on Windows where I was getting a strange runtime error ("Run-Time Check Failure #2 -S") which turns out was due to stack corruption. This was due to calling TIFFGetField with the wrong parameters, and that was because the field metadata in tif_dirinfo.c was wrong. Here's the broken bit:

         { TIFFTAG_COLORMAP, -1, -1, TIFF_SHORT, 0, TIFF_SETGET_OTHER,

TIFF_SETGET_UNDEFINED, FIELD_COLORMAP, 1, 0, "ColorMap", NULL },

These values are correct. There's field_passcount=0, which means you shouldn't be asking for the nunber of colors (&n in your code) from TIFFGetField. See:

https://github.com/vadz/libtiff/blob/c87dc82d7ff8214bd417176bd76f3fe94a237659/libtiff/tif_dir.c#L327

https://github.com/vadz/libtiff/blob/c87dc82d7ff8214bd417176bd76f3fe94a237659/libtiff/tif_dir.c#L939

TIFFGetField gives you the three uint16* pointers to r/g/b arrays, whose length, i.e. the number of colors in the palette, is determined by bitspersample (n = 1<<bitspersample)

Assuming I'm not totally wrong in my understanding, the wider question here is this: is the field metadata generally usable? Or does it need a proper audit of every field to ensure the types are correct in every case? Would it help to use the VARIABLE/VARIABLE2/SPP values in place of negative values?

There's a comment at the top acknowledging that symbolic names should be used, and something about formatting... I assume they'd make the table a bit harder to skim through.