[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Alternative proposal

• To: Multiple recipients of list <imgcif-l@bnl.gov>
• Subject: RE: Alternative proposal
• From: "J.W. Pflugrath" <JWP@msc.com>
• Date: Mon, 10 Jun 1996 12:50:52 -0400 (EDT)

Some quick comments on post ultimately from on
>   *** A STAR File approach to handling binary data
>                          Syd Hall and Nick Spadaccini

Most of the points made below have been made before since they are obvious.

>   We believe strongly that the simplest, most efficient and most elegant
>   approach to handling large scale binary data is that the experimental 
>   details describing the binary data, and the binary data be in two 
>   separate files. The former will be in a standard text STAR file 
>   (and recommend always archived with IUCr or whoever) and the latter 
>   in a binary file.
   
In practice, having 2 separate files complicates things enormously.  For
example, you make a tar or backup tape of your data.  If the ascii file
ends up on one tape and the binary file ends up on another tape you have
an annoying problem.

>   An important benefit of this approach is that a researcher wanting to review
>   the archived experimental paraameters does not have to load a massive binary
>   file to do so.  Most of the data items defined by Andy Hammersley would 
>   appear in the parameter file, though those special "header" names and 
>   clauses are now unnecessary (as they are non-conformant!).

Well, one need not load the entire file to view the experimental parameters.
They are in the header which can be read easily without reading the
binary data (e.g. on Unix systems: 'more image_file').
So this is not a benefit at all.

>...

>   Finally, Brian McMahon has suggested that because the ascii parameter 
>   (parent) file and the binary (child) file(s) are "detached", there may 
>   need to be a back pointer reference in the binary file. He suggests that,
   
>   > ....the binary file contain a back-pointer to the descriptor or catalogue
>   > file - i.e. the binary file could have a one-"line" header, padded to a
>   > block boundary if need be, something like
>   >
>   >   _catalogue_star_file         "/home/archive/expt_3.cat"
>   >
>   > The syntax need not be STAR-like, ....
>   >
>   >   catalogue_star_file="/home/archive/expt_3.cat"
   
Well, as long as we are putting a backpointer reference in the binary file,
why not put the whole set of experimental parameters there too?  If we are
going to do that, why not use a CIF(STAR-like) syntax?
   
>   * The impossiblility of imbedding binary data into ascii CIF files makes
>     it non-viable.

Has it been decided this was an impossibility?
   
>   ...
   
>   * What we propose provides a truly machine independent formalism which will
>     permit the use of all existing CIF/STAR software tools to check and parse
>     the file parameters.

Ok, we add a tool to strip the ASCII header off the binary image file to
yield what Syd Hall and Nick Spadaccini have proposed.  Or do CIF/STAR
tools recognize an end-of-CIF/STAR keyword.  If they did, they would be
able to work with an ASCII header-binary data file.

Summary: No clear arguments were given to not have an ASCII header-binary data
file.  Some minor arguments were given to keep the CIF/STAR standard pure.
But that does not prevent us with coming up with a
proposed standard ASCII header for our binary images.

Jim Pflugrath

Reply to: [list | sender only]

• Prev by Date: Alternative proposal
• Next by Date: Re: Alternative proposal
• Prev by thread: Alternative proposal
• Next by thread: Re: Alternative proposal
• Index(es):
  • Date
  • Thread