2011.07.28 03:40 "[Tiff] Non-TIff photon list psuedo image", by Richard Nolde

Terry,

Listen to these people. They know what they are talking about! There is no way your photon list data layout should be considered a TIFF image. I used to write MRI software and provided a TIFF export option for producing a true raster image of any time domain sample from a three dimensional MRI scan. This was a true image, viewable by any half decent Tiff viewer or native code written using VMS graphics libraries. It was not MRI data pretending to be a TIFF image. The original data were scaled before the export so as to make a viewable image. The same software could produce a custom file format with a published header format that contained all the metadata needed to understand the data as MRI samples. If you want to make your data usable by the scientific community, publish the spec for your raw file format and provide a simple open source C program to convert it to one or more image file formats. To make the format extensible, put a version number and header byte count in the first 8 or 16 bytes, maybe even such nicieties as host bit ordering of the writing machine. As long as you add your extensions to the end of the header and do not change the meaning of the earlier values, you can add features to your file format. The reader just checks the version number and loads the parameters that were defined for that version and then seeks to the end of the header to read the data If a new version has an header element that supersedes the old one, it should not be a big deal. In essence, you are borrowing the design of a TIFF file without the specific attributes that make a TIFF image by using a header length instead of a pointer to the location of the first data bytes.

   I have a raft of 20 year old C code written for a VAX under an NIH
grant that is therefore publicly shareable. It can export the raw 24 bit
non-IEEE floating point spectrometer data to 8, 16, or 32 bit integers
or floating point, both IEEE float and double and VAX GFloat format and
it supports big and little endian output. You can write the raw format
file in any simple/fast/small format that you desire. Given a good
metadata header, you can even do preliminary evaluation of a file to see
if it has anything worthwhile without loading the data portion of the
file. Since the raw binary file is seekable, you can even analyze the
data as you write your linked lists and update the metadata header
afterwards by seeking to the offset of specific items within the header
to update them. If you are interested in this approach, write me
offline for the code.

   Producing the raster from a list of coordinates and values would be
trivial to implement. It works just like a frame buffer. I used this
approach to overlay lines of specific palette colors to divide regions
of varying signal intensities. My custom palettes used values mapped to
various levels of gray for the lower half of the palette followed by a
series of colors for the overlaid lines that separated the regions of
higher signal intensity. You just decide what options to offer the user
for selecting and interpreting the data to be written to the raster.

Richard Nolde