[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [Imgcif-l] Pilatus 2M putative full CBF implementation
- To: The Crystallographic Binary File and its imgCIF application to image data <imgcif-l@iucr.org>
- Subject: Re: [Imgcif-l] Pilatus 2M putative full CBF implementation
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Sat, 2 Jul 2011 14:21:28 -0400
- In-Reply-To: <13999B6FC038EB44B067771E3CFBD091097228@EXCHMBX01.fed.cclrc.ac.uk>
- References: <13999B6FC038EB44B067771E3CFBD091097228@EXCHMBX01.fed.cclrc.ac.uk>
Dear Graeme, Nice job. The CBF's look pretty good in terms of following the "rules". I only see two small problems. Here's the list for G1F_3_0017.cbf: 1. CBFlib: warning input line 133 (19) -- item name _diffrn_scan_frame.exposure_time not found in the dictionary 2. CBFlib: warning -- required parent tag _array_data.binary_id for _diffrn_data_frame.binary_id in G1F_3_0017 not given CBFlib: warning -- required parent tag _array_data.binary_id for _array_intensities.binary_id in G1F_3_0017 not given Time to read input_cif: 0.414s Let's take them one at a time: 1. _diffrn_scan_frame.exposure_time really is not in dictionary and the DECTRIS tag you associate it with Exposure_period _expp_ really isn't so much an exposure time as an interval between exposures. I propose we add the following tags to the dictionary: _diffrn_scan.time_increment _diffrn_scan_frame.time_increment _diffrn_scan.time_rstrt_incr _diffrn_scan_frame.time_rstrt_incr The first two would be used for the Dectris "Exposure_period". The second two would be optional tags for the case where what we have is the time from end of one integration to the start of the next integration, rather then the time from start to start 2. _array_data.binary_id This seems to be missing. The value you give should agree with the value you use in _diffrn_data_frame.binary_id and _array_intensities.binary_id. In the past, we have always used 1, and that is the default, but I would suggest using the frame number (counting from 1) instead. If you do that, you should put the same value into _diffrn_scan_frame.frame_number. Ideally, this should start with a frame number in the DECTRIS header (that would be a new field, I believe) and would provide a cross-check on frame numbers, instead of just relying on the file name. Regards, Herbert At 3:44 PM +0000 6/30/11, <Graeme.Winter@Diamond.ac.uk> wrote: >Dear people interested in imgCIF, > >As you will no doubt know, we have been battling for a while to get >to generating full cbf images from our detectors. We have now >reached a milestone - full cbf images from Pilatus instruments which >cbflib recognises and can read, and that can be processed with our >automated software. However, we felt that it would be important to >make these data available for review among CIF experts to ensure >that there are no real boo boo's in there. > >So, a full Pilatus2M image data set can be found from: > >ftp://ftpanon.diamond.ac.uk/GraemeWinter/CBF/Pilatus2M/C.tar.bz2 > >which appears to process well using xia2 / XDS, which relies on >pycbf now included in cctbx to read the image headers and is >currently an unreleased version. It is unreleased for a good reason: >the assumptions which define the CIF in the images here are the same >set of assumptions used in understanding them, though the headers >are based on those from an ADSC Q315 so should be good. If you are >keen though you can get the bleeding edge code from sourceforge. > >The axes described are the "canonical" rather than true ones i.e. >they are where we would ideally like everything to be rather than >where everything is actually measured to be - the latter will be a >refinement at some point in the future. > >What would I like? People to download this, unpack it and critique >the headers which are contained therein. > >For people who are interested in the how, you will also find a .cif >file in the tarball - this was generated by GDA from a metatemplate >using some Python code and is used by the "camserver" program to >compose the full cbf image. Any errors in the CIF are therefore my >fault in composing this template and need fixing! > >Thanks in advance and best wishes, > >Graeme > >Dr. Graeme Winter >Senior Software Scientist >Diamond Light Source > >+44 1235 778091 (work) >+44 7786 662784 (work mobile) > > > > > >-- > >This e-mail and any attachments may contain confidential, copyright >and or privileged material, and are for the use of the intended >addressee only. If you are not the intended addressee or an >authorised recipient of the addressee please notify us of receipt by >returning the e-mail and do not use, copy, retain, distribute or >disclose the information in or attached to the e-mail. > >Any opinions expressed within this e-mail are those of the >individual and not necessarily of Diamond Light Source Ltd. > >Diamond Light Source Ltd. cannot guarantee that this e-mail or any >attachments are free from viruses and we cannot accept liability for >any damage which you may sustain as a result of software viruses >which may be transmitted in or with the message. > >Diamond Light Source Limited (company no. 4375679). Registered in >England and Wales with its registered office at Diamond House, >Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 >0DE, United Kingdom > > > > > > > > > >_______________________________________________ >imgcif-l mailing list >imgcif-l@iucr.org >http://scripts.iucr.org/mailman/listinfo/imgcif-l -- ===================================================== 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 ===================================================== _______________________________________________ imgcif-l mailing list imgcif-l@iucr.org http://scripts.iucr.org/mailman/listinfo/imgcif-l
Reply to: [list | sender only]
- Follow-Ups:
- Re: [Imgcif-l] Pilatus 2M putative full CBF implementation (Graeme.Winter)
- [Imgcif-l] Proposed new imgCIF/CBF dictionary (Herbert J. Bernstein)
- References:
- [Imgcif-l] Pilatus 2M putative full CBF implementation (Graeme.Winter)
- Prev by Date: Re: [Imgcif-l] Pilatus 2M putative full CBF implementation
- Next by Date: [Imgcif-l] Proposed new imgCIF/CBF dictionary
- Prev by thread: Re: [Imgcif-l] Pilatus 2M putative full CBF implementation
- Next by thread: [Imgcif-l] Proposed new imgCIF/CBF dictionary
- Index(es):