Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-q.b-one.net (mx-q.one.com [91.198.169.248])
	by mail9.b-one.net (Postfix) with ESMTP id 508AB400160
	for <info@awaresystems.be>; Thu, 28 Jul 2011 21:03:07 +0200 (CEST)
Received: by mx-q.b-one.net (Postfix, from userid 106)
	id 2CCD41D61B10; Thu, 28 Jul 2011 21:01:20 +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.091
X-Spam-Level: *
X-Spam-Status: No, score=1.091 tagged_above=0 required=4
 tests=[FRT_ADOBE2=1.099, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=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-q.b-one.net (Postfix) with ESMTP id 667651D45836 for
 <info@awaresystems.be>; Thu, 28 Jul 2011 21:01:15 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id 28B0F8730D; Thu, 28 Jul 2011
 14:00:09 -0500 (EST)
Received: from Agile-Automation.com
 (adsl-71-133-201-209.dsl.pltn13.pacbell.net [71.133.201.209]) by
 lists.maptools.org (Postfix) with ESMTP id A3FF38723C for
 <tiff@lists.maptools.org>; Thu, 28 Jul 2011 13:30:49 -0500 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2
Date: Thu, 28 Jul 2011 11:30:48 -0700
Message-ID:
 <6EF72F8D2EC2184184FB2204784CBCD31876B4@AgileServer.AgileDomain.local>
In-Reply-To: <14C93073F2584DF3A815D644CA737B47@AgileDomain.local>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tiff] Using photon lists rather than rasters
Thread-Index: AcxNTjQ2pLwmTo8sTQ+zMRvYo3qQmgAATuKQ
References:
 <6EF72F8D2EC2184184FB2204784CBCD31876AA@AgileServer.AgileDomain.local>,
 <CA55F3FA.44147%ccox@adobe.com>
 <14C93073F2584DF3A815D644CA737B47@AgileDomain.local>
From: "Terry L. Sprout" <Terry.Sprout@Agile-Automation.com>
To: "libtiff mailing list" <tiff@lists.maptools.org>
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="===============0019000174=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

This is a multi-part message in MIME format.

--===============0019000174==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CC4D54.78B06CD8"

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC4D54.78B06CD8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This has been an interesting thread. The final decision is to include
the image in the TIFF file and simply add the photon list as private
meta data. We will use integration methods to achieve compression
(integrating 1000 16-bit images gives a 2000:1 compression ratio) and
the TIFF file will include photon lists from all images used in the
integration. That will allow all TIFF readers to display the integrated
image and it will allow my software (and any other software that knows
how to read the photon lists) to use the photon lists to create images
with shorter exposures if desired. Including the image also allows users
to browse the hard drive when trying to find a specific set of images.

=20

In the future, I may choose to compress images further by setting the
bits/sample to the largest bit-depth in the image and then packing the
image. So images that are not integrated will be 1-bit/sample images,
which gives me another 8:1 compression ratio. I'm not sure if there is
enough value in packing bits, however, so I may never do it.

=20

I do want to mention one other thought. Some of you have indicated that
images described with a coordinate map is not an image. I am not aware
that the definition of an image has anything to do with its
representation. An image is the final result that is presented to the
user. A 2D array of intensities is no more an image than a list of
vectors or a list of coordinates. If an image is defined as a 2D array
of intensities, then I guess a 2D array of any A/D devices would also be
an image. So to argue that a representation of an image as a list of
coordinates does not fit the TIFF specification simply because it
doesn't fit your definition of an image is a bad argument. It is better
to say a TIFF image is expected to be comprised of rasters and not
coordinate maps.

=20

So I am in agreement that trying to use the TIFF structure for a photon
list with no raster image is an incorrect use of TIFF. If I want a
private use of a TIFF file, I might as well create my own file structure
(which would be easier) and provide instructions to anyone that needs to
read them.

=20

Thank you all for the opportunity to have this discussion.

=20

=20

Terry L. Sprout

=20

From: tiff-bounces@lists.maptools.org
[mailto:tiff-bounces@lists.maptools.org] On Behalf Of
rwong_002@hotmail.com
Sent: Thursday, July 28, 2011 10:46 AM
To: libtiff mailing list
Subject: Re: [Tiff] Using photon lists rather than rasters

=20

The idea about a better predictor to improve compression of niche
scientific images is interesting.=20
=20
Along the same direction, Terry could really use the new compression
type for that. Think about that: if it's a new predictor that nobody
today knows how to decode, and if it's much more advanced than today's
"TIFF predictor" (even though it is indeed a predictor in
mathematical/pedantic terms), it doesn't hurt to make its own
compression type.
=20
As for the photon images, it will require something superbly advanced
algorithms, something that blends several existing advanced algorithms
together that nobody has seen before. Like: multi-resolution (or
progressive-resolution), some kind of CABAC (which is both
context-sensitive and uses arithmetic coding), etc.
=20
That said, the larger TIFF community may try to compel you to (1) open
source your implementation and (2) give up, or sign over all
intellectual rights and copyrights of that specification, and for that
matter (3) it still leaves you vulnerable to patent lawsuits while the
larger TIFF community just sit and watch. Therefore, it's important to
remember that ultimately you have to decide what to do with your
invention; you may decide whether to open it or not. If in doubt, talk
to your company or employer lawyer.
=20
Thanks,
rwong_002@hotmail.com <mailto:rwong_002@hotmail.com>=20
=20
Disclaimer: The opinions expressed here are the views of the writer(s)
and do not necessarily reflect the views and opinions of the writers'
employer(s). Neither the writer(s), nor the writers' employers, make any
claim as to the accuracy of the opinions expressed here.
=20

________________________________

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


Tagged Image File Format.

I would rather not see a TIFF "image" that is not an image and is not
readable 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
more appropriate types.

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


Chris
=20


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

Ryan Wong wrote the following message and accidently sent it directly to
my email:
=20
***************************
Hello Terry,=20

TIFF is a raster image format, not a vector image format. Inside a TIFF
file, each page must contain exactly one raster image. It can contain
vector annotations 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 TIFF page can contain thumbnail images, which, like any
other metadata, can be ignored by viewers that do not support it.

No matter how hard you try, no current software would be able to decode
from your photons list. Even far into the future, mainstream software do
not have a need to support "photon lists", 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
accompanies with the original (unprocessed) image file. TIFF metadata
tags can store arbitrary byte data and do not have size limits (unless
going into the gigabytes range). This is the recommended way of storing
your coordinates data. 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 added as an optional part of any TIFF file.

If you do not take this approach, I don't think your proposal will be
accepted 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>=20
=20
Disclaimer: The opinions expressed here are the views of the writer(s)
and do not necessarily reflect the views and opinions of the writers'
employer(s). Neither the writer(s), nor the writers' employers, make any
claim as to the accuracy of the opinions expressed here.
***************************



Hello Ryan,
=20
Thank you for your comments.
=20
Including the original image doesn't help since one purpose is to create
smaller files so the drive doesn't fill up so fast. My software can
currently 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 times per second) and they only want to know where the photons
are located. They can then playback the photon list and create images
with different exposures. The original image will consume over 600 KB
per image (they're 2 bytes 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's a very good
compression ratio.
=20
I've decided to treat the coordinate list as a new compression type,
since that's basically what it is. When my new compression type is used
(34927), 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't understand the
compression type should ignore the image. I don't really expect most
people that provide TIFF readers to add this capability, but they can if
they want to view the images. The scientists that use this data will add
this capability because it helps them in their analysis.
=20


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


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


------_=_NextPart_001_01CC4D54.78B06CD8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:a=3D"urn:schemas-microsoft-com:office:access" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" =
xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" =
xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" =
xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" =
xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" =
xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" =
xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" =
xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" =
xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" =
xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" =
xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" =
xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" =
xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" =
xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" =
xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" =
xmlns:udc=3D"http://schemas.microsoft.com/data/udc" =
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" =
xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"=
 xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" =
xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" =
xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" =
xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" =
xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" =
xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" =
xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" =
xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" =
xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" =
xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig=
nature" =
xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi=
ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" =
xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"=
 =
xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag=
es" =
xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/=
" =
xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub=
lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" =
xmlns:st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [Tiff] Using photon lists rather than rasters</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Myriad Pro";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>This has been an interesting thread. The final decision =
is to
include the image in the TIFF file and simply add the photon list as =
private meta
data. We will use integration methods to achieve compression =
(integrating 1000
16-bit images gives a 2000:1 compression ratio) and the TIFF file will =
include
photon lists from all images used in the integration. That will allow =
all TIFF
readers to display the integrated image and it will allow my software =
(and any
other software that knows how to read the photon lists) to use the =
photon lists
to create images with shorter exposures if desired. Including the image =
also
allows users to browse the hard drive when trying to find a specific set =
of
images.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In the future, I may choose to compress images further by =
setting
the bits/sample to the largest bit-depth in the image and then packing =
the
image. So images that are not integrated will be 1-bit/sample images, =
which
gives me another 8:1 compression ratio. I&#8217;m not sure if there is =
enough
value in packing bits, however, so I may never do =
it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I do want to mention one other thought. Some of you have
indicated that images described with a coordinate map is not an image. I =
am not
aware that the definition of an image has anything to do with its =
representation.
An image is the final result that is presented to the user. A 2D array =
of intensities
is no more an image than a list of vectors or a list of coordinates. If =
an
image is defined as a 2D array of intensities, then I guess a 2D array =
of any A/D
devices would also be an image. So to argue that a representation of an =
image
as a list of coordinates does not fit the TIFF specification simply =
because it
doesn&#8217;t fit your definition of an image is a bad argument. It is =
better
to say a TIFF image is expected to be comprised of rasters and not =
coordinate
maps.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So I am in agreement that trying to use the TIFF =
structure for a
photon list with no raster image is an incorrect use of TIFF. If I want =
a
private use of a TIFF file, I might as well create my own file structure =
(which
would be easier) and provide instructions to anyone that needs to read =
them.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thank you all for the opportunity to have this =
discussion.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Terry L. Sprout<o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
tiff-bounces@lists.maptools.org
[mailto:tiff-bounces@lists.maptools.org] <b>On Behalf Of =
</b>rwong_002@hotmail.com<br>
<b>Sent:</b> Thursday, July 28, 2011 10:46 AM<br>
<b>To:</b> libtiff mailing list<br>
<b>Subject:</b> Re: [Tiff] Using photon lists rather than =
rasters<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>The
idea about a better predictor to improve compression of niche scientific =
images
is interesting. <br>
&nbsp;<br>
Along the same direction, Terry could really use the new compression
type&nbsp;for that. Think about that: if it's a new predictor that =
nobody today
knows how to decode, and if it's much more advanced than&nbsp;today's
&quot;TIFF predictor&quot; (even&nbsp;though it is indeed =
a&nbsp;predictor in
mathematical/pedantic terms), it doesn't hurt to make its own =
compression type.<br>
&nbsp;<br>
As for the photon images, it will require something superbly advanced
algorithms, something that blends several existing advanced algorithms =
together
that&nbsp;nobody has seen before. Like: multi-resolution (or
progressive-resolution), some kind of CABAC (which is both =
context-sensitive
and uses arithmetic coding), etc.<br>
&nbsp;<br>
That said, the larger TIFF community may&nbsp;try to compel you to (1) =
open
source&nbsp;your implementation and (2) give up, or sign over all =
intellectual
rights and&nbsp;copyrights of that specification, and for that matter =
(3) it
still leaves you vulnerable to patent lawsuits while the larger TIFF =
community
just sit and watch. Therefore, it's important to remember =
that&nbsp;ultimately
you have to decide what to do with your invention; you may&nbsp;decide =
whether
to open it or not. If&nbsp;in doubt, talk to your&nbsp;company or =
employer
lawyer.<br>
&nbsp;<br>
Thanks,<br>
<a href=3D"mailto:rwong_002@hotmail.com">rwong_002@hotmail.com</a> =
&lt;<a
href=3D"mailto:rwong_002@hotmail.com">mailto:rwong_002@hotmail.com</a>&gt=
;&nbsp;<br>
&nbsp;<br>
Disclaimer: The opinions expressed here are the views of the writer(s) =
and do
not necessarily reflect the views and opinions of the writers&#8217;
employer(s). Neither the writer(s), nor the writers&#8217; employers, =
make any
claim as to the accuracy of the opinions expressed here.<br>
&nbsp;<o:p></o:p></span></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>

<hr size=3D2 width=3D"100%" align=3Dcenter id=3DstopSpelling>

</span></div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From: ccox@adobe.com<br>
To: tiff@lists.maptools.org<br>
Date: Wed, 27 Jul 2011 16:57:30 -0700<br>
Subject: Re: [Tiff] Using photon lists rather than rasters<br>
<br>
</span><span style=3D'font-size:10.0pt;font-family:"Myriad =
Pro","serif"'><br>
Tagged Image File Format.<br>
<br>
I would rather not see a TIFF &#8220;image&#8221; that is not an image =
and is
not readable 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 =
more
appropriate types.<br>
<br>
Personally, I&#8217;d just apply a better predictor to improve =
compression and
keep the image data. &nbsp;If all you need are locations/centroids of =
photon
hits &#8211; you could easily convert the image to a 1 bit/sample
representation 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"http://Terry.Sprout@Agile-Automation.com" =
target=3D"_blank">Terry.Sprout@Agile-Automation.com</a>&gt;
wrote:</span><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><o:p></o:p><=
/span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:11.0pt;
font-family:"Myriad Pro","serif"'>Ryan Wong wrote the following message =
and
accidently sent it directly to my email:<br>
&nbsp;<br>
***************************<br>
</span><span style=3D'font-family:"Myriad Pro","serif"'>Hello Terry, =
<br>
</span><span style=3D'color:#1F497D'><br>
</span><span style=3D'font-family:"Myriad Pro","serif"'>TIFF is a raster =
image
format, not a vector image format. Inside a TIFF file, each page must =
contain
exactly one raster image. It can contain vector annotations 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 TIFF page can contain thumbnail =
images,
which, like any other metadata, can be ignored by viewers that do not =
support
it.<br>
</span><span style=3D'color:#1F497D'><br>
</span><span style=3D'font-family:"Myriad Pro","serif"'>No matter how =
hard you
try, no current software would be able to decode from your photons list. =
Even
far into the future, mainstream software do not have a need to support
&#8220;photon lists&#8221;, but they will happily render the raster =
image part
of a processed TIFF file.<br>
</span><span style=3D'color:#1F497D'><br>
</span><span style=3D'font-family:"Myriad Pro","serif"'>My suggestion is =
to store
the coordinates as a metadata tag, which accompanies with the original
(unprocessed) image file. TIFF metadata tags can store arbitrary byte =
data and
do not have size limits (unless going into the gigabytes range). This is =
the
recommended way of storing your coordinates data. And yes, floating =
point
(32-bit, 64-bit and all IEEE-approved ones) are supported in =
metadata.<br>
</span><span style=3D'color:#1F497D'><br>
</span><span style=3D'font-family:"Myriad Pro","serif"'>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>
</span><span style=3D'color:#1F497D'><br>
</span><span style=3D'font-family:"Myriad Pro","serif"'>If you do not =
take this
approach, I don&#8217;t think your proposal will be accepted by the =
larger TIFF
community at all. In particular, modifications to NewSubFileType, =
proposals to
support a StripByteCount of zero, will be shot down immediately.<br>
</span><span style=3D'color:#1F497D'><br>
</span><span style=3D'font-family:"Myriad Pro","serif"'>Thanks,<br>
<span style=3D'color:#1F497D'><a href=3D"http://rwong_002@hotmail.com"
target=3D"_blank">rwong_002@hotmail.com</a></span></span><span =
style=3D'color:#1F497D'>
&lt;<a =
href=3D"mailto:rwong_002@hotmail.com">mailto:rwong_002@hotmail.com</a>&gt=
;
<br>
&nbsp;<br>
</span><span style=3D'font-family:"Myriad Pro","serif"'>Disclaimer: The =
opinions
expressed here are the views of the writer(s) and do not necessarily =
reflect the
views and opinions of the writers&#8217; employer(s). Neither the =
writer(s),
nor the writers&#8217; employers, make any claim as to the accuracy of =
the
opinions expressed here.<br>
</span><span style=3D'font-size:11.0pt;font-family:"Myriad =
Pro","serif"'>***************************<br>
</span><span style=3D'font-size:10.0pt;font-family:"Myriad =
Pro","serif"'><br>
<br>
<br>
</span><span style=3D'font-size:11.0pt;font-family:"Myriad =
Pro","serif"'>Hello
Ryan,<br>
&nbsp;<br>
Thank you for your comments.<br>
&nbsp;<br>
Including the original image doesn&#8217;t help since one purpose is to =
create
smaller files so the drive doesn&#8217;t fill up so fast. My software =
can
currently 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 =
times
per second) and they only want to know where the photons are located. =
They can
then playback the photon list and create images with different =
exposures. The
original image will consume over 600 KB per image (they&#8217;re 2 bytes =
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&#8217;s a very good compression ratio.<br>
&nbsp;<br>
I&#8217;ve decided to treat the coordinate list as a new compression =
type,
since that&#8217;s basically what it is. When my new compression type is =
used
(34927), 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&#8217;t understand the compression =
type
should ignore the image. I don&#8217;t really expect most people that =
provide
TIFF readers to add this capability, but they can if they want to view =
the
images. The scientists that use this data will add this capability =
because it
helps them in their analysis.<br>
&nbsp;<br>
</span><span style=3D'font-size:10.0pt;font-family:"Myriad =
Pro","serif"'><br>
</span><span style=3D'font-size:11.0pt;font-family:"Myriad =
Pro","serif"'><br>
Terry L. Sprout<br>
(510) 324-5501<br>
w7-32<br>
&nbsp;</span><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
_______________________________________________ Tiff mailing list:
Tiff@lists.maptools.org http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/<o:p></o:p></span></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01CC4D54.78B06CD8--

--===============0019000174==
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/
--===============0019000174==--
