Status: Read
Received: from [207.176.88.85] by phillip.cerious.com (NTMail 3.03.0017/7.aaxh) with ESMTP id pcrews for <pcrews@cerious.com>; Mon, 13 Nov 2000 10:34:42 -0500
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id KAA16787;
	Mon, 13 Nov 2000 10:30:50 -0500
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Mon, 13 Nov 2000 10:29:34 -0500
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id KAA16682
	for tiff-outgoing; Mon, 13 Nov 2000 10:29:34 -0500
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from maildrop.velocet.net (maildrop.velocet.net [216.126.74.5])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id KAA16679
	for <tiff@olympiakos.com>; Mon, 13 Nov 2000 10:29:31 -0500
Received: from home.com (H216.C51.tor.velocet.net [204.138.51.216])
	by maildrop.velocet.net (Postfix) with ESMTP id 41C2E729A
	for <tiff@olympiakos.com>; Mon, 13 Nov 2000 10:29:24 -0500 (EST)
Message-ID: <3A100ABE.C3AE12E9@home.com>
Date: Mon, 13 Nov 2000 10:37:34 -0500
From: Frank Warmerdam <warmerda@home.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: TIFF Mailing List <tiff@olympiakos.com>
Subject: Outstanding Libtiff Issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tiff@olympiakos.com

Folks, 

The following two issues were submitted into bugzilla on the weekend (along
with a couple of others I dealt with), and look like they deserve attention.
However, I am a bit tired after my fight with YCbCr support a few weeks ago.

Anyone interested in pursuing these problems should let me know, and I will
happly turn the requests over to them.:

==============================================================================

http://bugzilla.remotesensing.org/show_bug.cgi?id=22

A 16-bit logarithmic luminance presumably has more than 8 bits of linear
precision, but currently the only option for automatically converting to
"normal" grayscale or RGB is SGILOGDATAFMT_8BIT.  (SGILOGDATAFMT_16BIT sounds
like it would Do the Right Thing, but instead it converts the integer log(L) to
floating-point L and leaves the U and V values, if any, alone.)  It would be
nice to have an SGILOGDATAFMT_16BIT_INT (or similar) that would convert LOGL and
LOGLUV to 16-bit-per-sample, linear, integer grayscale and RGB, respectively. 
This would be of use in tiff2png and presumably even in tiffcp.

==============================================================================

http://bugzilla.remotesensing.org/show_bug.cgi?id=23

http://www.ai.sri.com/cgi-bin/digitalearth/list.pl?dir=sfbay.oi

The images at the URL above, in varying resolutions, are all tiled YCbCr TIFFs
with JPEG compression.  Not all tools handle YCbCr TIFFs or tiled TIFFs (or
both), so it would be nice if tiffcp did.  But despite its lack of diagnostics,
when run on such an image with only the -s option, tiffcp produces a tiny file
with mangled Y, Cb and Cr components (at least judging by XV's output).  For
example, the 512x640 level-4 image shrinks from 240k to 33k and changes from a
reasonable aerial shot (with black regions indicating no data) to a mostly teal
image.  Since the tiles are (reported to be) 128x128 pixels, it should be
possible to losslessly convert such an image into strips of 512x128 pixels (or
so I would imagine--I'm no TIFF expert).

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerda@home.com
light and sound - activate the windows | http://members.home.com/warmerda
and watch the world go round - Rush    | Geospatial Programmer for Rent
