Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-k.b-one.net (mx-k.one.com [91.198.169.58])
	by mail9.b-one.net (Postfix) with ESMTP id 5068C400164
	for <info@awaresystems.be>; Mon,  2 Nov 2009 23:29:30 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-k.b-one.net (Postfix) with ESMTP id 85AA9C22092
	for <info@awaresystems.be>; Mon,  2 Nov 2009 23:29:29 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 03F2F1D191D80;
	Mon,  2 Nov 2009 17:27:22 -0500 (EST)
Received: from isadora.cybox.com (isadora.cybox.com [206.168.112.10])
	by lists.maptools.org (Postfix) with ESMTP id 453C01D18B14F
	for <tiff@lists.maptools.org>; Mon,  2 Nov 2009 16:59:53 -0500 (EST)
Received: from boreas.wriverody.net (vc7-1-52.dsl.netrack.net [199.45.160.84]
	(may be forged)) (authenticated)
	by isadora.cybox.com (msa 8.13.8/8.13.6) with ESMTP id nA2Lxmbq028153; 
	Mon, 2 Nov 2009 14:59:49 -0700
Message-ID: <4AEF564F.9090305@cybox.com>
Date: Mon, 02 Nov 2009 14:59:43 -0700
From: Richard Nolde <richard.nolde@cybox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11
	Thunderbird/3.0b4
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
References: <4AEF1C2D.9070907@cybox.com>
	<alpine.GSO.2.01.0911021231460.1964@freddy.simplesystems.org>
In-Reply-To: <alpine.GSO.2.01.0911021231460.1964@freddy.simplesystems.org>
Cc: "Joris Van Damme \(AWare Systems\)" <info@awaresystems.be>,
	Tiff Listserve <tiff@lists.maptools.org>
Subject: [Tiff] Tiffcrop test suite and logluv issues
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

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

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
