Discussion List Archives

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

imageNCIF Convergence ?

	Andy has summarised very well the consensus that is developing 
in the group, but it is important to point out that, however much 
the ascii part of the binary file may look like a cif, it will not be a 
cif as long as it is included in a file that contains binary 
information.  If the ascii text is extracted (possibly without any 
alteration) into a file that contains no binary sections, then it might 
well be a cif, and comcifs would need to approve its adoption.  Comcifs 
as a committee would have nothing to say about the validity of the ascii 
text once it were embedded into the binary file.

	Still, it would make sense to keep the ascii part in a form that, 
when extracted, constituted a legitimate cif.  In this way, any cif could 
be embedded in the binary file in order to keep the image data together 
with the associated crystallographic information, the the cif could later be 
removed and treated by normal cif-reading software.

	Andy's second part draws attention to another restriction in cif
which might cause problems, and that is the rule that each data name (e.g. 
_image_data_type) can only be used once in a data block.  This is causing
some problems in other cif dictionaries and these problems have not been
entirely resolved.  It means that the header I gave in my last comment
could only be used once, so that the information about only one image
could be given in a datablock unless the images are included in a loop. 
However, only one level of loop is allowed in cif, so the presence of the
loop in the example I gave would prevent the images from also being looped. 
This restriction, which is a consequence of the difficulty of reading
nested loops, has the effect of making the datanames more specific, not
less.  Generic names starting with _binary_*, for example, would allow the
description of only one binary block per cif data block.  The tendency in
cif would be not only to have different data names for headers of
different kinds of binary blocks but to have different datanames for
different kinds of images, e.g.  _image_raw_data_*,
_image_corrected_data_*, etc., which would allow several different image
headers to appear in the same data block.  It is true that this
restriction tends to fill the dictionaries with more names, but it does
provide a very precise description of the crystallographic function of
each image, which is helpful to the crystallographic software that has to
process the information. 


				David Brown

*****************************************************
Dr.I.D.Brown
Brockhouse Institute for Materials Research, 
McMaster University, Hamilton, Ontario, Canada
1-(905)-525-9140 ext 24710
*****************************************************

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links