LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
November 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.11.02 21:59 "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
compiling on a little endian host (having just gone through this with
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++) {
tp[i] = bp[0] << 16 | bp[1] << 8 | bp[2];
bp += 3;
cc -= 3;
}
Richard Nolde