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

Re: CIF or NOT CIF, (or nothing)

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

Hi Everyone,

I have a few comments on the comments !

1. The term archiving has come up a few times. i.e. "CIF is an archive"
   format, and Yves thinks that one of the aims of "imageNCIF" should be 
   to archive images.

   My (limited) understanding on present CIF, is that it is mainly used as a
   standardized way of submitting (processed) crystallographic data to
   Acta Cryst. Of course this doesn't mean that Acta Cryst. and others don't
   archive the entries.

   What is meant and implied by "archive" ?

   Does it mean any more than: "The format must be supported (supportable) 
   in the future, and must be appropriate for present and forseeable 
   technology." ?
 
2. The difference between proposal 2 and 4. 

   Proposal 2 involves a separate "header" file, and a separate "data" 
   (binary) file. Proposal 4 (in at least one scenerio) would store both 
   "header" information and "data" in the same file.

   An advantage of proposal 2 (compared to 4) would be that existing CIF
   tools would be able to work directly on the "header" file. For 4, if the
   "header" section is very similar to CIF, then an extraction tool could be
   used to extract the header section and create an ASCII file which could 
   then be used with standard CIF tools. If the format used is well
   defined and simply related to CIF (whilst being "binary"), this extraction 
   tool could be very simple to write, and be very portable.

   A disadvantage of proposal 2 is that a single "image" would be stored in 
   two separate files. This provides the opportunity for the "header"
   information to be separated from the "data" (Remember Murphy's law)
   Depending on how a sequence of n "images" was stored, you might have
   2*n files or n+1 files.

   Image formats of type 2 do exist (e.g. Hamburg OTOKO / BSL) format, but 
   the vast majority of existing image formats fall into the category defined
   by proposal 4.

3. Is "BINARY" a dirty word ?

   10 years ago I guess the answer was YES. Today I don't think it is.
   With internet/ftp/WWW, etc. many people pass pictures of naked women 
   (and occasionally other things) around the world without even thinking 
   of all the potential problems. TIFF and many other "binary" formats 
   show that byte ordering differences etc. can be handled (I use TIFF as
   an example as it is entirely binary based, including the "header" 
   information.) Personnally I'm still uneasy about floating point 
   representations, but for integer based images practically there is no
   longer an issue. 

   Yves says that "images should be easily transfered through the network."
   An aim with which I'm sure most of us would agree. However, this is NOT 
   reality at present, at least not for the quantity and size of images 
   which many scientists produce. From or to the ESRF I think around
   10 Mbytes is the practical limit which can be successfully transferred
   over internet. This of course is a bandwidth/shared usage limitation and
   we can all hope will increase with time, and some of you may be luckier. 
   What does this mean, if anything, for image formats: 1: Transfer by 
   tape, WORMs, etc. will continue to be a major need; 2. Efficient 
   compression is desirable.

4. Graphical Description of "image" data.

   I think that I understand the idea, and Brian has now given examples,
   however I can't see this working in practice. My main aim would be the
   transfer of raw detector data from acquisition point to analysis 
   software. For this I don't want to loss any information whatsoever, so the
   value (and meaning) of every single pixel/bin needs to be preserved.    
   The crystallographic information in the image, is much smaller than this,
   but if you want to check that the detector was working properly that day, 
   it can be very useful to look at the exact distribution of pixel/bin
   values.

   Even if a suitable form could be developed for a Laue image, how could that 
   be used for a small angle scattering image ? At present we are talking 
   about crystallographic "images" of many different types.

5. The aim of ("imageNCIF") 

   Yes, the aim is essentially the same as that of the IUCr CIF project.
   I added the word "experimental" on a re-wording, partly to make my 
   definition different that of the CIF project ! So if the basic aims
   are exactly the same, why should the mechanism for achieving them be 
   different ?

   1. The world has changed (slightly) since CIF was set-up. See above.
      Whilst I agree that CIF must maintain backwards compatibility,
      it seems unwise to try to restrict an image format of today
      (and the future) to this past.

   2. The scale of the problem is completely different. Once data is 
      processed to a list of hkl's and I's, or somethingelse, the quantity
      of information is enormously reduced from the raw data. This is 
      another reason that I feel that the word "experimental" is useful.

      One difference of the scale of information, is the desirability of
      human-readability and (ASCII) print-outs of image data. Most people 
      (I believe) do not want text print-outs of the pixel values of
      1000x1000 pixel images. False colour representations/ 3-d surface 
      plots/ contour plots etc. are generally much more useful.

    Given both common aims and vast scale differences, is it not wise to
    develop separate, but related formats ?

Thanks for the replies.

Seasonal Greeting,

                    Andy

Reply to: [list | sender only]

• Prev by Date: Re: CIF or NOT CIF, (or nothing)
• Next by Date: Re: CIF or NOT CIF, (or nothing)
• Prev by thread: Re: CIF or NOT CIF, (or nothing)
• Next by thread: Re: CIF or NOT CIF, (or nothing)
• Index(es):
  • Date
  • Thread