Dear Herbert & group, I concur with Herbert's message below. The "mini" part is useful to have, but it should be assumed that the actual CBF is the governing header. While we are transitioning from older formats to CBF format, the ascii version of the "legacy header" should be used for consistency checking and fixing things should an error in the CBF header items be discovered after the fact. This *greatly* reduces the anxiety level of users since we know the binary part of the format is solid and replicates the original data and so the only thing which can mess up is a header goof, and that's recoverable with the legacy header. Chris -----Original Message----- From: imgcif-l-bounces@iucr.org on behalf of Herbert J. Bernstein Sent: Wed 9/12/2007 2:46 PM To: Harry Powell Cc: The Crystallographic Binary File and its imgCIF application to image data Subject: Re: [Imgcif-l] CBF Format Dear Harry, Actually you can have your miniCBF header and full header, too, even for MAR. If you look at the file converted_flat_orig.cbf in the CBFlib data files kit, you will see; _diffrn_frame_data.id FRAME1 _diffrn_frame_data.detector_element_id ELEMENT1 _diffrn_frame_data.array_id ARRAY1 _diffrn_frame_data.binary_id 1 _diffrn_frame_data.details ; DETECTOR = MAR 345; PIXEL SIZE = 0.15 0.15; WAVELENGTH = 1.080000; DISTANCE = 240; OSCILLATION AXIS = PHI; PHI = 0; OSCILLATION RANGE = 1; PROGRAM = mar345 Version 0.8.6; DATE = Thu Dec 4 10:23:48 1997; SCANNER = 26; FORMAT = 2300 PCK 5290000; HIGH = 155; PIXEL = LENGTH 150 HEIGHT 150; OFFSET = ROFF 5.000 TOFF 0.000; MULTIPLIER = 1.000; GAIN = 1.000; RESOLUTION = 1.761; PHI.. = START 0.000 END 1.000 OSC 1; OMEGA = START 0.000 END 0.000 OSC 0; CHI = 0.000; TWOTHETA = 0.000; CENTER = X 1150.000 Y 1150.000; MODE = TIME; EXPOSURE TIME = 20.00; COUNTS = START 19.35 END 19.29 NMEAS 9; COUNTS.. = MIN 19.27 MAX 19.38; COUNTS.... = AVE 19.30 SIG 0.03; INTENSITY = MIN 1 MAX 249051 AVE 207.8 SIG 951.09; HISTOGRAM = START 0 END 2023 MAX 28307; GENERATOR = ROTATINGANODE kV 10.0 mA 20.0; MONOCHROMATOR = GRAPHITE POLAR 0.000; COLLIMATOR = WIDTH 0.30 HEIGHT 0.30; ; I added this to extra copy of header information to the output of convert_image when I was working with Chris on the ADSC header. I proved so useful there, that I put it in for MAR as well and would suggest it for all detectors. ===================================================== Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 +1-631-244-3035 yaya@dowling.edu ===================================================== On Wed, 12 Sep 2007, Harry Powell wrote: > Hi > > I'd like to concur with Nick. As far as Mosflm is concerned, the miniCBF > is not a CBF. In my opinion, it should not be called "anything" CBF. > Developers of some other integration programs have been rather less polite > (privately) in their descriptions of the miniCBF. > > My understanding is that the miniCBF was developed for the Pilatus > detector for processing with XDS - which does not use image header > information except for the image size and compression algorithm (and it > gets these from the MIME part). > > If you include the CIF fields that are present in images from the ADSCs at > Diamond, you will not be going far wrong - see an example header at > > http://www.mrc-lmb.cam.ac.uk/harry/herb.header > > (this is a file I prepared for Herb a little while ago, and not linked to, > so you need to use this URL). Note that it also includes the normal ADSC > header information as a properly-formed CIF comment (i.e. free text > delimited by ";" on lines on their own), but this is not parsed by Mosflm. > MarCCD headers, being binary encoded, would probably not be usefully > reproduced in the CBF header! > > The beamline and data acquisition staff at Diamond expect all their PX > area detectors to write CBFs in the same form with the same header > information as proper CIF items; the image compression algorithm is up to > the detector manufacturer, as long as it is one of those supported by > CBFlib. > > >From a personal point of view, I think it would be really nice if all CBFs > (at least in the same field) conformed to the same format! > > > Thanks for working on CBF support for the Mar CCD. The image processing > > program LABELIT expects full CBF, not miniCBF. The MIME area is not > > parsed. You are correct in identifying the "non-optional" data items. > > This is as far as my expertise goes...it would be quite helpful if some > > Mar datasets written in CBF format were to be made available. The most > > useful test cases would be those where the direct beam is offset from > > the detector center, but not at a 45- or 90-degree position angle. Full > > datasets would be most useful. > > > > Nick Sauter > > > > Justin Anderson wrote: > > > >> Hello everyone, > >> > >> My name is Justin Anderson with Rayonix (formerly MarUSA). I have been > >> given the task of adding CBF format support to the marccd program. I > >> was hoping you could help me with a few questions that have arisen. I > >> truly appreciate it. > >> > >> Now for the questions... > >> > >> 1) Are miniCBF files meant to be read by imaging programs such as > >> marccd or are they expected to be converted to full CBF format first? > >> > >> 2) What is the minimum set of fields that is necessary for an official > >> miniCBF and CBF file? In the "Simple Example Header" in section 2 of > >> the Draft Format > >> (http://www.iucr.org/iucr-top/cif/cbf/cbf_definition.html) it does > >> mention at one point that "the above" data items are optional. Does > >> that imply that the items below are required? > >> > >> 3) Some items can exist in both the header area and the MIME area. One > >> such example is the image size (e.g. fastest and second-fastest number > >> of pixels). When reading a CBF file, should I expect to get that > >> information from the MIME, the CBF header area or would it be found in both? > >> > >> I appreciate any help you can give me. > >> > >> > >> > >> Justin Anderson Rayonix, LLC (Formerly Mar USA) > >> Software Engineer justin@rayonix.com > >> 1880 Oak Ave. Ste. 120 Evanston, IL, USA 60201 > >> 877.627.9729 847.869.1548 > >> > >> _______________________________________________ > >> imgcif-l mailing list > >> imgcif-l@iucr.org > >> http://scripts.iucr.org/mailman/listinfo/imgcif-l > >> > >> > > > > -- > > Nicholas K. Sauter, Ph.D. > > Lawrence Berkeley National Laboratory > > 1 Cyclotron Road > > Berkeley, CA 94720 > > > > nksauter@lbl.gov > > Voice: 510-486-5713 > > Fax: 510-486-5909 > > _______________________________________________ > > imgcif-l mailing list > > imgcif-l@iucr.org > > http://scripts.iucr.org/mailman/listinfo/imgcif-l > > > > Harry > -- > Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills > Road, Cambridge, CB2 2QH > > _______________________________________________ > imgcif-l mailing list > imgcif-l@iucr.org > http://scripts.iucr.org/mailman/listinfo/imgcif-l > _______________________________________________ imgcif-l mailing list imgcif-l@iucr.org http://scripts.iucr.org/mailman/listinfo/imgcif-l
_______________________________________________ imgcif-l mailing list imgcif-l@iucr.org http://scripts.iucr.org/mailman/listinfo/imgcif-l
Copyright © International Union of Crystallography
IUCr Webmaster