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

CIF or NOT CIF, (or nothing)

• To: Multiple recipients of list <imgcif-l@bnl.gov>
• Subject: CIF or NOT CIF, (or nothing)
• From: Andy Hammersley <hammersl@esrf.fr>
• Date: Sun, 17 Dec 1995 08:06:36 -0500 (EST)

Hi Everyone,

Brian McMahon has suggested 3 "possible" ways in which image type data
could be stored within the existing CIF concept. He also asks for a
definition of the "goals" of the project.

So here is my attempt at defining the "goal". Please comment if you have
additions / deletions to make to my definition. Even if you agree with my
definition, perhaps you can re-word it in a better manner ! 

-------------------------------------------------------------------------------

The aim of ("imageNCIF") is to "standardize" the passing of image (and other) 
crystallographic experimental data (1) from: one institute to another;
one make of computer system to another; and from one computer program 
(acquisition or analysis) to another (2). If a sufficiently large number
of institutes/ programmers/ and producers of detector equipment can
agree on a common format then the present task of having to support 
numerous new and different image (data) formats will be at least 
lessened (3).

Notes:

1. Here mainly raw detector data and partially processed data, or
   simulated detector data, are being considered. Mainly images and
   sequences of images are involved, although 1-D data may also be
   concerned. The typical present size of single images is a few
   Mbytes, although single images of around 100 Mbytes exist, and
   complete data-sets may easily be 100's of Mbytes. 

2. This implies an inter-continental scope.

3. This implies that the format must be flexible enough to cover a variety
   of needs. However, does not mean that every conceivable need must be 
   addressed (immediately).

-------------------------------------------------------------------------------

I think it would be useful to have everyones views on the 3 proposals
raised by Brian, plus the proposal to base any format on something which
is NOT CIF in the strict sense. And in fairness to certain views, I also
add a 5th "proposal": "Do nothing". So can I ask everyone to at least give a
comment on the 5 choices (or on others), concerning the basic support 
mechanism for the file format:

  1: CIF based, using encoding to convert binary data to ASCII

  2: CIF based "header file", using file pointers to point to binary file(s)

  3: CIF based "graphics" description of binary data

  4: Break with existing CIF to at least some extent, probably because a
     file contains binary data. This could be "CIF" sections within a binary
     files, or could be any other non-CIF format.

  5: Do nothing. 

(I hope this is a fair description of the proposals. Are there any other
CIF compliant possibilities ?)

Could everyone provide at least one word answers with their views on
these proposals ? (e.g. 1: MAYBE, 2: O.K. 3: NO WAY, 4: NO WAY, 5: NO
[these are not necessarily my views]) 

-------------------------------------------------------------------------------

Some feedback of HDF and APS would be useful. Steve, or Cele, could you
perhaps sound out the feeling of the APS and institutes involved at the
APS with regards to HDF, and/or "imageNCIF", and/or other formats ?


Wishing everyone a Merry Christmas and a Happy start to the New Year,
followed of course by an equally happy continuation.

       Andy

Reply to: [list | sender only]

• Prev by Date: MIF description
• Next by Date: Re: CIF or NOT CIF, (or nothing)
• Prev by thread: Some suggestions on image data files
• Next by thread: Re: CIF or NOT CIF, (or nothing)
• Index(es):
  • Date
  • Thread