LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
July 2011

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems

2011.07.28 03:40 "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