[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [Imgcif-l] CBF file templates
- To: The Crystallographic Binary File and its imgCIF application to image data <imgcif-l@iucr.org>
- Subject: Re: [Imgcif-l] CBF file templates
- From: harry powell <harry@mrc-lmb.cam.ac.uk>
- Date: Wed, 30 Sep 2009 10:09:12 +0100
- In-Reply-To: <4854F2500EA8C4478A508D2D92973E52047BE33D@EXCHANGE25.fed.cclrc.ac.uk>
- References: <4854F2500EA8C4478A508D2D92973E52047BE339@EXCHANGE25.fed.cclrc.ac.uk><20090929061322.N74653@epsilon.pair.com><4854F2500EA8C4478A508D2D92973E52047BE33D@EXCHANGE25.fed.cclrc.ac.uk>
Hi a single "?" in an empty field is allowed under CIF rules, as I understand. ISTR it from the days when I deposited CIFs for small molecule structures, and CBF is supposed to be conformant to the normal CIF rules (apart from the binary section, about which people may argue). d*Trek has to be the model of being comprehensive apropos its use of the header. I don't think HKL is an issue, to be honest - I think I'm right in saying that Wladek has said that "CBF is just another image format" - they will use what they see as useful and/or necessary. On 30 Sep 2009, at 09:45, Winter, Graeme (DLSLtd,RAL,DIA) wrote: > Dear Herbert & list, > > One template per beamline is probably, in reality, the way it would > work. We would just make sure that they are all the same. Adding ???? > For the detector software to fill in sounds like good sense. Is this > kind of thing supported? An alternative is to have some boiler plate > which needs to be copied in, then work on getting the format for the > detector produced bit the same. These are essentially the same > problem. > > What's the consensus on the best approach? Does everyone support > the use > of templates? > > At the other end, I assume that the contents of the current ADSC CBF > header represent the minimum which should be in place for e.g. > Mosflm to > make sense of the image, and anything we add will be ignored. XDS > ignores the header anyway. D*TREK, HKL - any comments? > > Thanks, > > Graeme > > -----Original Message----- > From: imgcif-l-bounces@iucr.org [mailto:imgcif-l-bounces@iucr.org] On > Behalf Of Herbert J. Bernstein > Sent: 29 September 2009 11:34 > To: The Crystallographic Binary File and its imgCIF application to > image > data > Subject: Re: [Imgcif-l] CBF file templates > > Dear Colleagues, > > Right now the utilities in the library use templates that are > intended to be for just one beamline per template, so they are set up > with tags with zero values for the items that they know will be > populated from the detector and known specific values for the beamline > for items that come from the beamline geometry. If we are going to > have > master templates, there would seem to be more cases: > > 1. Items that will be supplied by every detector. > 2. Items that will be supplied by some detectors but not others > 3. Items that will be supplied by every beamline > 4. Items that will be supplied by some beamlines but not > others > > I would suggest using "?", rather than "0" values for all items > that are > know known for sure in writing the master template. Then in > specializing > for a given beamline (e.g. in setting up the axes), all of the "?" for > 3, hopefully a lot for 4 could be removed and replaced with known > values. > When the detector data is merged with the beam-line specific tempate, > hopefully all "?" for 1 and a lot for 2 would be replaced with data > from > the detector. The "?" that are left would then be clear markers of > what > was supplied neither by the beamline nor by the detector. I am > working > on the code to allow comments to be preserved and copied along with > data, so we could carry remarks such as: > > # This item should be supplied by every beamline > # This item should be supplied on beamlines ..., ... ... > # This item should be supplied by every detector > # This item should be supplied by detectors ..., ... ... > > or is people, prefer, we can add CIF tags with the same info > > Regards, > Herbert > ===================================================== > 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 Tue, 29 Sep 2009, Winter, Graeme (DLSLtd,RAL,DIA) wrote: > >> Dear CBF'ers, >> >> I'm working on trying to establish a "Diamond standard" template for >> our CBF files across a number of detectors, and I was wondering how >> this is best specified. What would be ideal would be to set up a >> template which contains those things that the beamline "knows" but >> the > >> detector does not, then have the detector software populate the other > fields (e.g. >> exposure time, integration time, maximum trusted pixel, oscillation >> start / end) to give a full description. >> >> Now, has anyone done something like this? If so, how do you specify >> the fields which are to be replaced? If not, does anyone have an >> opinion on how this should be done? >> >> Thanks, >> >> Graeme >> >> Graeme Winter >> Software and MX Support 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 >> > _______________________________________________ > imgcif-l mailing list > imgcif-l@iucr.org > http://scripts.iucr.org/mailman/listinfo/imgcif-l > 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 Harry -- Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills Road, Cambridge, CB2 0QH _______________________________________________ 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] CBF file templates (Ashton, Alun (DLSLtd,RAL,DIA))
- References:
- [Imgcif-l] CBF file templates (Winter, Graeme (DLSLtd,RAL,DIA))
- Re: [Imgcif-l] CBF file templates (Herbert J. Bernstein)
- Re: [Imgcif-l] CBF file templates (Winter, Graeme (DLSLtd,RAL,DIA))
- Prev by Date: Re: [Imgcif-l] CBF file templates
- Next by Date: Re: [Imgcif-l] CBF file templates
- Prev by thread: Re: [Imgcif-l] CBF file templates
- Next by thread: Re: [Imgcif-l] CBF file templates
- Index(es):