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

2011.07.28 00:45 "Re: [Tiff] Using photon lists rather than rasters", by Daniel McCoy

Reading these photon files would require rendering to convert them into the kind of raster image that TIFF readers expect.

There should be other file formats which might be more suited for this.

An example would be RenderMan's "point cloud" file:

    http://cgkit.sourceforge.net/doc2/pointcloud.html

From "Terry L. Sprout" <Terry.Sprout@Agile-Automation.com>, Wed, Jul 27, 2011 at 09:39:00AM -0700:

I write Scientific Imaging software that writes TIFF files. I recently add the ability to locate photons in an image with sub-pixel accuracy. The original image is then discarded and a new image can be created from the list of photons. I want to write a TIFF file that provides this list instead of the standard raster image. I already registered an IFD tag with Adobe for this purpose and I already devised a scheme.

I am interested in knowing if this has already been defined since it would be advantageous to use known schemes so other TIFF readers can understand these files. The whole purpose of using TIFF files is to create files that can be read by others, and I would like to continue.

I am also interested in knowing if more bits in the NewSubfileType have already been defined. I think these files should be identified with a bit set so the reader knows the image is defined by a series of coordinates rather than a series of strips. How do I register a new bit?

This also begs the question of how other readers will handle a file with no strips. Of course, I'm not quite sure how that would be done. It seems the best way to provide an empty image is to set the StripByteCount tag to 0. I assume the StipOffset tag cannot be zero since that simply points to the beginning of the file, the RowsPerStrip tag cannot be zero since that might cause a divide-by-zero error for those readers that calculate the number of strips per image.

Perhaps this could be considered a new compression type instead (no need for a sub file type). How do I register a compression type, or is there already one that exists for coordinate-based pixels? (The coordinates must be floating-points since they represent sub-pixel accuracy.)