Received: by smtp02.oce.nl (4.1/SMI-4.1)
	id AA23192; Tue, 22 Sep 98 18:09:53 +0200
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oce.nl (8.9.0/8.9.0) with ESMTP id RAA03798
	for <rvdt@oce.nl>; Tue, 22 Sep 1998 17:41:43 +0200 (MET DST)
Received: from odin.corp.sgi.com (fddi-odin.corp.sgi.com [198.29.75.194]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id IAA02168; Tue, 22 Sep 1998 08:39:14 -0700 (PDT)
	mail_from (owner-tiff@fddi-sgi.sgi.com)
Received: from sgi.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI)
	 id IAA20546; Tue, 22 Sep 1998 08:40:46 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA04173; Tue, 22 Sep 1998 08:40:25 -0700 (PDT)
	mail_from (owner-tiff@sgi.engr.sgi.com)
Received: (from majordomo-owner@localhost)
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	id HAA28299
	for tiff-list;
	Tue, 22 Sep 1998 07:52:19 -0700 (PDT)
	mail_from (owner-tiff@sgi.sgi.com)
Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA39552
	for <tiff-relay@cthulhu.engr.sgi.com>;
	Tue, 22 Sep 1998 07:52:17 -0700 (PDT)
	mail_from (owner-tiff@sgi.sgi.com)
Received: from hq15.pcmail.ingr.com (hq15.pcmail.ingr.com [129.135.251.243]) 
	by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA02391
	for <tiff@sgi.com>; Tue, 22 Sep 1998 07:52:15 -0700 (PDT)
	mail_from (egrissom@ingr.com)
Received: by HQ15 with Internet Mail Service (5.5.2232.9)
	id <TLG116AP>; Tue, 22 Sep 1998 09:52:16 -0500
Message-Id: <FC51EB665B3FD211A516080009B94E43624473@HQ5>
From: "Grissom, Ed" <egrissom@ingr.com>
To: tiff@sgi.com
Subject: Transparent pixel value (no transparency mask) 
Date: Tue, 22 Sep 1998 09:52:15 -0500
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: owner-tiff@fddi-sgi.sgi.com
Precedence: bulk


This message is one of a series of messages with questions about advanced
raster topics and TIFF.  See the message entitled "Tiff Questions - TIFF
7.0 ?" for more info.


- Transparent pixel value (no transparency mask) 

In previous messages on the TIFF list, others have asked if there were any
way to specify a pixel value that should be treated as transparent.

We are also interested in a solution to this problem.  As far as I can
tell, the only way to do transparency is to either use ExtraSamples and
have a Alpha Mask that basically has 0% for transparent pixels and 100% for
non-transparent pixels, or to have a multi-image file (linked list of IFDs)
where the second image can be a transparency bitmask.

While this solution is valid, it presents difficulties in practice.  Most
of our applications are geared toward greyscale and RGB images only.  We do
not normally deal with Alpha channels.  To be able to handle transparency
with some "overlay" image would require either single-bit image processing
to be added to these application or Alpha channel handling to be added.  On
the other hand, a designated pixel value that is transparent can easily be
added since we already have this capability in our internal format.

One other solution is to use the TransparencyIndicator TAG from the TIFF/IT
specification.  However this TAG is limited to certain image types, and a
full-blown TIFF/IT implementation should not be needed just to have
transparency. 

When working on satellite data or aerial photographs, we typically have to
resampling and rectifying these images to fit a projection model that is
being used to work with the data.  Since it is unlikely that the edges of
the sat. image or the photo will match up with vertical and horizontal
grids in the projection, the resampled images typically have triangular
areas near each of the edges without valid data.  We would like to be able
to specify zero as the transparency value, fill the triangular edges with
zeros, and during the resampling process change any "real" zero value found
in the file to one (so that no areas inside the image are transparent).

Obviously, this cannot be guaranteed to work correctly for JPEG compressed
files since you cannot be sure that the compression process will not change
the "one" back to a "zero".  Also, applications that need more than one
transparent value will probably be better served with the current
implementation of a bit-mask.

I think the addition of a tag to specify a transparent value would be a
great addition to TIFF.

Is there any chance that some feature like this could be added to TIFF ?
One that is less restrictive than the TIFF/IT definition ?
Perhaps in 7.0 or in a new Tech. Note ?

--
ed grissom
egrissom@ingr.com

