2009.11.02 21:59 "[Tiff] Tiffcrop test suite and logluv issues", by Richard Nolde

Regarding testing.

All tigers tests look good with multiple rotations, extractions, flips, etc. and no compiler errors or warnings.

All tiffcrop tests in the test suite except the logluv 1x1 pixel test work correctly with 60 x 60 extracts and the report below is just what it should be. We can either remove that test or use a larger image.

tiffcrop -E left -Z1:4,2:4 ./images/logluv-3c-16b.tiff o-tiffcrop-extractz14-logluv-3c-16b.tiff extractContigSamplesBytes: Invalid end column value 0 ignored.

extractContigSamplesBytes: Invalid end column value 0 ignored. o-tiffcrop-extractz14-logluv-3c-16b.tiff: Error, can't write strip 0.: Unable to write contiguous strip data for page 0. /home/nolde/Tiff/libtiff/tools/tiffinfo -D o-tiffcrop-extractz14-logluv-3c-16b.tiff TIFFReadDirectory: Cannot handle zero scanline size. Returned failed status 1!

Regarding logluv images in testpics set:

I've updated my copies from CVS head and 3.9.1 branch. I found and fixed some code that I added in an attempt to prevent users from trying to use LOGLUV with compression other than SGILOG or SGILOG24. Tiffcp doesn't prevent users from trying to convert from one compression scheme to another even if the photometric interpretation is not compatible. Now that the corrected test works, I'm poking into the problem of why the image looks wrong after using tiffcp or tiffcrop to copy it. The output of tiffinfo and tiffdump don't point up amy differences but tiffcmp shows that data for sample 0 are changed between input and output files. In most cases, every pixel shows a single change but there are some lines with multiple changes for a single pixel. Since the TAGS are not changed between input and output files, I'm wondering if there is a problem with the logluv codec? The comments in the source code indicate that SGILOG compression can be used with 16 bit grayscale or 32 bit color data but SGILOG24 is only used with color data.

Original code from tiffcp:
     if (compression == COMPRESSION_SGILOG || compression ==
COMPRESSION_SGILOG24)
       TIFFSetField(out, TIFFTAG_PHOTOMETRIC, spp == 1?
             PHOTOMETRIC_LOGL: PHOTOMETRIC_LOGLUV);
     else
       TIFFSetField(out, TIFFTAG_PHOTOMETRIC, image->photometric);

Additional corrected code in tiffcrop:

    if (((input_photometric == PHOTOMETRIC_LOGL) ||
        (input_photometric == PHOTOMETRIC_LOGLUV)) &&
       ((compression != COMPRESSION_SGILOG) &&
        (compression != COMPRESSION_SGILOG24)))
     {
     TIFFError("writeCroppedImage",
               "LogL and LogLuv source data require SGI_LOG or SGI_LOG24
compression");
     return (-1);
     }

tiffinfo /archive/libtiff/libtiffpic/off_luv24.tif
TIFF Directory at offset 0x36e10 (224784)
   Image Width: 333 Image Length: 225
   Resolution: 72, 72 pixels/inch
   Bits/Sample: 16
   Sample Format: signed integer
   Compression Scheme: SGILog24
   Photometric Interpretation: CIE Log2(L) (u',v')
   Orientation: row 0 top, col 0 lhs
   Samples/Pixel: 3
   Rows/Strip: 8
   Planar Configuration: single image plane
   Sample to Nits conversion factor: 1.7900e+02

tiffcmp -l /archive/libtiff/libtiffpic/off_luv24.tif /tmp/off_luv24.tif | grep 'Scanline 0'

Scanline 0, pixel 0, sample 0: 3c1a 43fe
Scanline 0, pixel 1, sample 0: 3c1a 43fe
Scanline 0, pixel 2, sample 0: 3c1a 43fe
Scanline 0, pixel 3, sample 0: 3c1a 43fe
Scanline 0, pixel 4, sample 0: 3c1a 43fe
Scanline 0, pixel 5, sample 0: 3c1a 43fe
Scanline 0, pixel 6, sample 0: 3c1a 43fe
Scanline 0, pixel 7, sample 0: 3c1a 43fe
Scanline 0, pixel 8, sample 0: 3c1a 43fe
Scanline 0, pixel 9, sample 0: 3c1a 43fe
...
Scanline 0, pixel 241, sample 0: 3dde 43fe
Scanline 0, pixel 242, sample 0: 3dde 43fe
Scanline 0, pixel 242, sample 0: 1ae9 1a97
Scanline 0, pixel 242, sample 0: 3ca1 3c2f

Every pixel shows at least one change for sample 0, a few pixels show multiple changes. Since tiffcp doesn't do anything but copy scanlines, unlike tiffcrop which loads the image into memory so that it can be manipulated, it is hard to figure out why the data would change unless,

as I suspect, the following code from tif_luv.c doesn't take into

consideration the fact that the original data is bigendian and I am on a little endian host (having just gone through this with compiling

Toby's patch suggestion.) In fact, running tiffcp or tiffcrop with the -B switch to generate big endian TIFF produces quite a different result for both off_luv24.tif and off_luv32.tif.

LogLuvDecode24(TIFF* tif, tidata_t op, tsize_t occ, tsample_t s)

{
         LogLuvState* sp = DecoderState(tif);
         int cc, i, npixels;
         unsigned char* bp;
         uint32* tp;

         assert(s == 0);
         assert(sp != NULL);

         npixels = occ / sp->pixel_size;

         if (sp->user_datafmt == SGILOGDATAFMT_RAW)
                 tp = (uint32 *)op;
         else {
                 assert(sp->tbuflen >= npixels);
                 tp = (uint32 *) sp->tbuf;
         }
                                         /* copy to array of uint32 */
         bp = (unsigned char*) tif->tif_rawcp;
         cc = tif->tif_rawcc;

          for (i = 0; i < npixels && cc > 0; i++) {
 = bp[0] << 16 | bp[1] << 8 | bp[2];tp[i]

                 bp += 3;
                 cc -= 3;
         }

Richard Nolde