2011.07.27 16:39 "[Tiff] Using photon lists rather than rasters", by Terry L. Sprout

2011.07.28 00:31 "Re: [Tiff] Using photon lists rather than rasters", by Terry L. Sprout

The 1 bit/sample idea would work if the coordinates were not sub-pixel resolution and if there was only one time-point of photons in the list. Another issue I have is the time it will take to perform the compression. Some cameras I deal with today acquire 1000 ips and we are moving into > 20,000 ips. It's difficult enough writing the original image; compression will be worse.

I understand your concerns regarding undocumented custom compression types. After all, what is the point of using a standard file format if most readers cannot display the image.

What if I publish the compression scheme?

Terry L. Sprout

(510) 324-5501

w7-32

From: tiff-bounces@lists.maptools.org [mailto:tiff-bounces@lists.maptools.org] On Behalf Of Chris Cox

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, 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. I'd -

Chris

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:

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

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 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. don't

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 employer(s). Neither the writer(s), nor the employers, make any claim as to the accuracy of the opinions expressed here. writers' writers'
***************************

Hello Ryan,

Thank you for your comments.

Including the original image help since one purpose is to create smaller files so the drive 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 doesn't doesn't