Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-j.b-one.net (mx-j.one.com [91.198.169.57])
	by mail9.b-one.net (Postfix) with ESMTP id 062D1400160
	for <info@awaresystems.be>; Thu, 28 Jul 2011 13:57:31 +0200 (CEST)
Received: by mx-j.b-one.net (Postfix, from userid 106)
	id EFA0F3E04E9E; Thu, 28 Jul 2011 13:57:05 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: 1.09
X-Spam-Level: *
X-Spam-Status: No, score=1.09 tagged_above=0 required=4
 tests=[FRT_ADOBE2=1.099, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01]
 autolearn=disabled
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-j.b-one.net (Postfix) with ESMTP id 175233DE677E for
 <info@awaresystems.be>; Thu, 28 Jul 2011 13:57:03 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id DFFE087183; Thu, 28 Jul 2011
 06:55:46 -0500 (EST)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37])
 by lists.maptools.org (Postfix) with SMTP id 9F827872BA for
 <tiff@lists.maptools.org>; Thu, 28 Jul 2011 06:48:39 -0500 (EST)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by
 exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID
 DSNKTjFMlmzrtyUy970nevbNX7/PMxA00UVK@postini.com; Thu, 28 Jul 2011 04:49:00
 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com
 [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with
 ESMTP id p6SBlJC7012238 for <tiff@lists.maptools.org>; Thu, 28 Jul 2011
 04:47:20 -0700 (PDT)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98])
 by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p6SBmYMT002196
 for <tiff@lists.maptools.org>; Thu, 28 Jul 2011 04:48:35 -0700 (PDT)
Received: from NAMBX02.corp.adobe.com ([10.8.127.96]) by
 nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Thu, 28 Jul 2011 04:48:34
 -0700
From: Leonard Rosenthol <lrosenth@adobe.com>
To: Chris Cox <ccox@adobe.com>, TIFF <tiff@lists.maptools.org>
Date: Thu, 28 Jul 2011 04:48:31 -0700
Thread-Topic: [Tiff] Using photon lists rather than rasters
Thread-Index: AcxNHEbzPtZYhiGIRE27CKpgbVOj5Q==
Message-ID: <CA56C46A.72DA%lrosenth@adobe.com>
In-Reply-To: <CA55F3FA.44147%ccox@adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.12.0.110505
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Tiff] Using photon lists rather than rasters
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: multipart/mixed; boundary="===============0016811576=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

--===============0016811576==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_CA56C46A72DAlrosenthadobecom_"

--_000_CA56C46A72DAlrosenthadobecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

As much as I hate to correct Chris in public, I am inclined to point out th=
at while no one disputes that the ORIGINAL definition of "TIFF" was the acr=
onym stated below, the actual fact is that the spelled out version NEVER ap=
pears in the actual "standard" (TIFF v6).  So that OFFICIALLY it is just "T=
IFF".

Leonard

From: Chris Cox <ccox@adobe.com<mailto:ccox@adobe.com>>
Date: Wed, 27 Jul 2011 16:57:30 -0700
To: TIFF <tiff@lists.maptools.org<mailto:tiff@lists.maptools.org>>
Subject: Re: [Tiff] Using photon lists rather than rasters


Tagged Image File Format.

I would rather not see a TIFF =93image=94 that is not an image and is not r=
eadable by other software.
TIFF already gets too much abuse with undocumented custom compression types=
 that render the files useless.

In this case you are creating a vector display list, for which there are mo=
re appropriate types.

Personally, I=92d just apply a better predictor to improve compression and =
keep the image data.  If all you need are locations/centroids of photon hit=
s =96 you could easily convert the image to a 1 bit/sample representation a=
nd compress that.


Chris



On 7/27/11 3:51 PM, "Terry L. Sprout" <Terry.Sprout@Agile-Automation.com> w=
rote:

Ryan Wong wrote the following message and accidently sent it directly to my=
 email:

***************************
Hello Terry,

TIFF is a raster image format, not a vector image format. Inside a TIFF fil=
e, each page must contain exactly one raster image. It can contain vector a=
nnotations in metadata, but viewers are not required to render it. It will =
most likely be ignored by most TIFF viewers that do not understand it. A TI=
FF page can contain thumbnail images, which, like any other metadata, can b=
e ignored by viewers that do not support it.

No matter how hard you try, no current software would be able to decode fro=
m your photons list. Even far into the future, mainstream software do not h=
ave a need to support =93photon lists=94, but they will happily render the =
raster image part of a processed TIFF file.

My suggestion is to store the coordinates as a metadata tag, which accompan=
ies with the original (unprocessed) image file. TIFF metadata tags can stor=
e arbitrary byte data and do not have size limits (unless going into the gi=
gabytes range). This is the recommended way of storing your coordinates dat=
a. And yes, floating point (32-bit, 64-bit and all IEEE-approved ones) are =
supported in metadata.

Viewers that do not understand your photons list will simply ignore it, and=
 will still display the unprocessed image. Similar to the way EXIF can be a=
dded as an optional part of any TIFF file.

If you do not take this approach, I don=92t think your proposal will be acc=
epted by the larger TIFF community at all. In particular, modifications to =
NewSubFileType, proposals to support a StripByteCount of zero, will be shot=
 down immediately.

Thanks,
rwong_002@hotmail.com <mailto:rwong_002@hotmail.com>

Disclaimer: The opinions expressed here are the views of the writer(s) and =
do not necessarily reflect the views and opinions of the writers=92 employe=
r(s). Neither the writer(s), nor the writers=92 employers, make any claim a=
s to the accuracy of the opinions expressed here.
***************************



Hello Ryan,

Thank you for your comments.

Including the original image doesn=92t help since one purpose is to create =
smaller files so the drive doesn=92t fill up so fast. My software can curre=
ntly fill up a hard drive at 240 MB/s. Some people are using a camera that =
outputs very sparse photons (maybe 100 photons from a 300 KB image 120 time=
s per second) and they only want to know where the photons are located. The=
y can then playback the photon list and create images with different exposu=
res. The original image will consume over 600 KB per image (they=92re 2 byt=
es per pixel) or 73 MB/s; or 4.8 GB/m; or 262 GB/h. In contrast, the photon=
 list will only consume about 400 bytes per image; or 48 KB/s; or 2.9 MB/m;=
 or 173 MB/h. That=92s a very good compression ratio.

I=92ve decided to treat the coordinate list as a new compression type, sinc=
e that=92s basically what it is. When my new compression type is used (3492=
7), my new coordinate list tag (51098) must be used as well. The coordinate=
 list tag is a pointer to a linked list of IFDs that will contain a list of=
 pixel coordinates along with a list of intensity values (and a timestamp).=
 TIFF readers that don=92t understand the compression type should ignore th=
e image. I don=92t really expect most people that provide TIFF readers to a=
dd this capability, but they can if they want to view the images. The scien=
tists that use this data will add this capability because it helps them in =
their analysis.



Terry L. Sprout
(510) 324-5501
w7-32



--_000_CA56C46A72DAlrosenthadobecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space;=
 -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14p=
x; font-family: Calibri, sans-serif; "><div>As much as I hate to correct Ch=
ris in public, I am inclined to point out that while no one disputes that t=
he ORIGINAL definition of &quot;TIFF&quot; was the acronym stated below, th=
e actual fact is that the spelled out version NEVER appears in the actual &=
quot;standard&quot; (TIFF v6). &nbsp;So that OFFICIALLY it is just &quot;TI=
FF&quot;.</div><div><br></div><div>Leonard</div><div><br></div><span id=3D"=
OLK_SRC_BODY_SECTION"><div style=3D"font-family:Calibri; font-size:11pt; te=
xt-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium=
 none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-T=
OP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span s=
tyle=3D"font-weight:bold">From: </span> Chris Cox &lt;<a href=3D"mailto:cco=
x@adobe.com">ccox@adobe.com</a>&gt;<br><span style=3D"font-weight:bold">Dat=
e: </span> Wed, 27 Jul 2011 16:57:30 -0700<br><span style=3D"font-weight:bo=
ld">To: </span> TIFF &lt;<a href=3D"mailto:tiff@lists.maptools.org">tiff@li=
sts.maptools.org</a>&gt;<br><span style=3D"font-weight:bold">Subject: </spa=
n> Re: [Tiff] Using photon lists rather than rasters<br></div><div><br></di=
v><div><div><font face=3D"Myriad Pro"><span style=3D"font-size:10pt"><br>
Tagged Image File Format.<br><br>
I would rather not see a TIFF =93image=94 that is not an image and is not r=
eadable by other software.<br>
TIFF already gets too much abuse with undocumented custom compression types=
 that render the files useless.<br><br>
In this case you are creating a vector display list, for which there are mo=
re appropriate types.<br><br>
Personally, I=92d just apply a better predictor to improve compression and =
keep the image data. &nbsp;If all you need are locations/centroids of photo=
n hits =96 you could easily convert the image to a 1 bit/sample representat=
ion and compress that.<br><br><br>
Chris<br>
&nbsp;<br><br><br>
On 7/27/11 3:51 PM, &quot;Terry L. Sprout&quot; &lt;<a href=3D"Terry.Sprout=
@Agile-Automation.com">Terry.Sprout@Agile-Automation.com</a>&gt; wrote:<br>=
<br></span></font><blockquote><font face=3D"Myriad Pro"><font size=3D"4"><s=
pan style=3D"font-size:11pt">Ryan Wong wrote the following message and acci=
dently sent it directly to my email:<br>
&nbsp;<br>
***************************<br></span><span style=3D"font-size:12pt">Hello =
Terry, <br></span></font></font><font size=3D"4"><span style=3D"font-size:1=
2pt"><font color=3D"#1F497D"><font face=3D"Times New Roman"> <br></font></f=
ont><font face=3D"Myriad Pro">TIFF is a raster image format, not a vector i=
mage format. Inside a TIFF file, each page must contain exactly one raster =
image. It can contain vector annotations in metadata, but viewers are not r=
equired to render it. It will most likely be ignored by most TIFF viewers t=
hat do not understand it. A TIFF page can contain thumbnail images, which, =
like any other metadata, can be ignored by viewers that do not support it.<=
br></font><font color=3D"#1F497D"><font face=3D"Times New Roman"> <br></fon=
t></font><font face=3D"Myriad Pro">No matter how hard you try, no current s=
oftware would be able to decode from your photons list. Even far into the f=
uture, mainstream software do not have a need to support =93photon lists=94=
, but they will happily render the raster image part of a processed TIFF fi=
le.<br></font><font color=3D"#1F497D"><font face=3D"Times New Roman"> <br><=
/font></font><font face=3D"Myriad Pro">My suggestion is to store the coordi=
nates as a metadata tag, which accompanies with the original (unprocessed) =
image file. TIFF metadata tags can store arbitrary byte data and do not hav=
e size limits (unless going into the gigabytes range). This is the recommen=
ded way of storing your coordinates data. And yes, floating point (32-bit, =
64-bit and all IEEE-approved ones) are supported in metadata.<br></font><fo=
nt color=3D"#1F497D"><font face=3D"Times New Roman"> <br></font></font><fon=
t face=3D"Myriad Pro">Viewers that do not understand your photons list will=
 simply ignore it, and will still display the unprocessed image. Similar to=
 the way EXIF can be added as an optional part of any TIFF file.<br></font>=
<font color=3D"#1F497D"><font face=3D"Times New Roman"> <br></font></font><=
font face=3D"Myriad Pro">If you do not take this approach, I don=92t think =
your proposal will be accepted by the larger TIFF community at all. In part=
icular, modifications to NewSubFileType, proposals to support a StripByteCo=
unt of zero, will be shot down immediately.<br></font><font color=3D"#1F497=
D"><font face=3D"Times New Roman"> <br></font></font><font face=3D"Myriad P=
ro">Thanks,<br><font color=3D"#1F497D"><a href=3D"rwong_002@hotmail.com">rw=
ong_002@hotmail.com</a></font></font><font color=3D"#1F497D"><font face=3D"=
Times New Roman"> &lt;<a href=3D"mailto:rwong_002@hotmail.com">mailto:rwong=
_002@hotmail.com</a>&gt; <br>
&nbsp;<br></font></font><font face=3D"Myriad Pro">Disclaimer: The opinions =
expressed here are the views of the writer(s) and do not necessarily reflec=
t the views and opinions of the writers=92 employer(s). Neither the writer(=
s), nor the writers=92 employers, make any claim as to the accuracy of the =
opinions expressed here.<br></font></span><font face=3D"Myriad Pro"><span s=
tyle=3D"font-size:11pt">***************************<br></span></font></font=
><font face=3D"Myriad Pro"><span style=3D"font-size:10pt"><br><br><br></spa=
n><font size=3D"4"><span style=3D"font-size:11pt">Hello Ryan,<br>
&nbsp;<br>
Thank you for your comments.<br>
&nbsp;<br>
Including the original image doesn=92t help since one purpose is to create =
smaller files so the drive doesn=92t fill up so fast. My software can curre=
ntly fill up a hard drive at 240 MB/s. Some people are using a camera that =
outputs very sparse photons (maybe 100 photons from a 300 KB image 120 time=
s per second) and they only want to know where the photons are located. The=
y can then playback the photon list and create images with different exposu=
res. The original image will consume over 600 KB per image (they=92re 2 byt=
es per pixel) or 73 MB/s; or 4.8 GB/m; or 262 GB/h. In contrast, the photon=
 list will only consume about 400 bytes per image; or 48 KB/s; or 2.9 MB/m;=
 or 173 MB/h. That=92s a very good compression ratio.<br>
&nbsp;<br>
I=92ve decided to treat the coordinate list as a new compression type, sinc=
e that=92s basically what it is. When my new compression type is used (3492=
7), my new coordinate list tag (51098) must be used as well. The coordinate=
 list tag is a pointer to a linked list of IFDs that will contain a list of=
 pixel coordinates along with a list of intensity values (and a timestamp).=
 TIFF readers that don=92t understand the compression type should ignore th=
e image. I don=92t really expect most people that provide TIFF readers to a=
dd this capability, but they can if they want to view the images. The scien=
tists that use this data will add this capability because it helps them in =
their analysis.<br>
&nbsp;<br></span></font><span style=3D"font-size:10pt"><br></span><font siz=
e=3D"4"><span style=3D"font-size:11pt"> <br>
Terry L. Sprout<br>
(510) 324-5501<br>
w7-32<br>
&nbsp;<br></span></font><span style=3D"font-size:10pt"><br></span></font></=
blockquote></div></div></span></body></html>

--_000_CA56C46A72DAlrosenthadobecom_--

--===============0016811576==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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