[Nexus] DECTRIS again
Tobias.Richter at diamond.ac.uk
Tobias.Richter at diamond.ac.uk
Mon Oct 22 14:59:37 BST 2012
Hi all,
I did recall us deciding something for the exposure_time, but at least it wasn't known to all in this mailing list.
The scheme would work with something like this:
detector:NXdetector
data[j,k,l] = [....]
detector_arm[1] = [250]
@transformation=translation
@vector={1,0,0}
@units=cm
@depends_on=/entry/instrument/something/brick
depends_on=detector_arm
module:NXdetector_module
data_origin[2] = [l,m]
data_size[2] = [n,o]
module_offset[1] = [250]
@transformation=translation
@vector={0,1,1}
@units=mm
@depends_on="../detector_arm"
fast_pixel_direction[1] = [0.172]
@transformation=translation
@vector={1,0,0}
@units=mm
@depends_on="module_offset"
slow_pixel_direction[1] = [0.172]
@transformation=translation
@vector={0,1,0}
@units=mm
@depends_on="module_offset"
module:NXdetector_module
....
This is just a (hopefully) complete illustration to show what we need to specify. I am more than happy for suggestions to modify this.
We would also need to make sure that interpreting the detector in the traditional way fails. Otherwise software will pick up the wrong geometry.
I am not sure why we are in such a rush, though. They are not about to ship a detector like that in the next days, are they? We can put something like the above in front of them and say that is vaguely what it will contain. But we will need to put some thought into it. In the end the way we currently use the Pilatus that information would be written by me anyway as I have no intention updating the detector on its geometry all the time.
Bottom line is: It should not be too obvious that institutions actually devoting manpower towards NeXus do not receive the same fast-track service for their requirements.
Regards,
Tobias
________________________________________
From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on behalf of Mark Koennecke [Mark.Koennecke at psi.ch]
Sent: 19 October 2012 16:25
To: Discussion forum for the NeXus data format
Subject: Re: [Nexus] DECTRIS again
Tobias, Pete,
On 10/18/2012 05:06 PM, Tobias.Richter at diamond.ac.uk wrote:
> Hi,
>
> I'm with Ben on the critique of the "exposure_time".
I was of the impression that we decided on the last Telco to make them
use count_time.
This is what I forwarded to them.
> For the modules one problem is that the "data" will be one big image array. So we need to identify the module slice with something [x,y,dx,dy]. This would apply to the last slicerank/2 dimensions of the dataset (in case of scans).
>
> With that if you have one displaced module were this in the data:
>
> +--------------+
> | |
> | |
> | |
> | +----+
> | | |
> +---------+----+
>
> Is actually like this in real space:
>
> +--------------+ +----+
> | | | |
> | | +----+
> | |
> | +----+
> | |
> +---------+
>
>
> You would need to describe that as at least three modules unless we make the scheme more complex.
>
> For the elements the (simplified) CIF standard uses
> * an origin relative to the nominal detector position
> * a fast vector with pixel displacement along it
> * a slow vector with pixel displacement along it
> The detector normal is in the direction of the cross product of the two vectors.
> There are more complicated schemes for non-regular/rectangular, e.g. hexagonal pixels. I'd suggest we deal with those as and when required.
Can you please give an example of a NXdetector_element group with this?
I agree that having those
arrays is a tad overkill.
Concerning Pete's reply:
yes, NXdetector is the class which would benefit the most if we take
apart NeXus to become
more OO-oriented. IMHO, in NXdetector there are two opposing forces:
- We already have a means to describe each detector pixel individually.
This is the most general
case. But this is cumbersome.
- We wish to maintain the spatiality of the detector in order to give
the user what she expects: if she
has an area detector, she should see that on file. And not a
description of each pixel.
When entering the realm of OO-NeXus I am now starting to think more of
interfaces. OO does not match so
well anyway. And I have reservation against a more complicated hierarchy
anyway.
The interface approach would mean: You start with a plain NXdetector, if
you a 2D you add these fields,
if you have TOF do this, if you have 2D and TOF do this, etc.
So, I think we could go quick with a solution to the problem: if you
have a patched together detector
do this. I do wish to give DECTRIS a timely answer on this. May be
modelled on CIFS approach.
Have a nice weekend,
Mark
> I am not sure how this translates into your second option, Mark.
> If we assume the pizels are all evenly spaced, I think we do not need the arrays for the positions, though.
>
> Comments?
>
> Tobias
>
> ________________________________________
> From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on behalf of Watts Benjamin [Benjamin.Watts at psi.ch]
> Sent: 04 October 2012 15:07
> To: Discussion forum for the NeXus data format
> Subject: Re: [Nexus] DECTRIS again
>
> Hi,
> I'm happy with all the names except that "exposure_time", which is
> clearly used in contradiction to the meaning of the word "exposure" and
> the nature of the hardware. (Only a light source or shutter would
> control an actual exposure time.) If a new field is required, then I
> would prefer it be named "accumulation_time". However, the field
> "count_time" already exists in NXdetector and would suit the purposes of
> DECTRIS perfectly well. My reccommendation therefore is that DECTRIS use
> "count_time" instead of making a new "exposure_time" field.
>
> For describing the positions of the detector modules, I vote for the
> CIF-like option since forward-compatibility is more of an issue than
> backwards-compatibility in this case.
>
> Cheers,
> Ben
>
>
> -----Original Message-----
> From: nexus-bounces at nexusformat.org
> [mailto:nexus-bounces at nexusformat.org] On Behalf Of Mark Koennecke
> Sent: Donnerstag, 4. Oktober 2012 14:39
> To: Discussion forum for the NeXus data format
> Subject: [Nexus] DECTRIS again
>
> Hi,
>
> there are still some open points about the DECTRIS detector which have
> come up.
>
> First the time issue: I got better documentation what the times actually
> mean:
>
> frame_time = exposure_time + detector_readout_time
> frame_time: time at which data is sent to readout-computer, i.e.
> defines the speed of the data collection or the
> speed and can be put on the same level as
> exposure time for an integrating detector
> (like a CCD, Imaging Plate,...)
> exposure_time: time during which detector counts X-rays
> detector_readout_time: time the detector takes for a complete readout
> of all chips, i.e. defines the minimum time after
> which the detector can count
> again
>
> With this explanation, are we now happy with the names?
>
> And a new issue came up: detector modules. The EIGER detector consists
> of various modules which are arranged to build the full detector. There
> are gaps between the modules. The EIGER SW calculates a combined image
> from the contributions of the modules. In the case of a flat detector
> the DA SW looks at the mask to find out about gaps.
> Happiness al around.
>
> But the modules may be arranged along an arbitrary form, may be half
> sphere. The detector SW will still recombine the modules to an image,
> just for the user to look at it. But then the DA SW needs the position
> and orientation of the individual modules. And an indication at which
> indices the module starts in the combined image. The question is now how
> to describe those modules. As the DA may need it, this is no longer
> DECTRIS private but should be addressed by us.
>
> The first option would be to have NXgeometries in NXdetector:
>
> NXdetector
> module01,NXgeometry
> NXtranslation
> NXorientation
>
> module02,NXgeometry
> NXtranslation
> NXorientation
>
> .....
> This option is missing the index information. I am not sure if we want
> to add that to NXgeometry. I am also not sure if we still wish to
> advocate the use of NXgeometry. IMHO, the CIF mapping is better and
> NXgeometry may be deprecated soon.. But is not yet....
>
> The second option would be a new group: NXdetector_module looking like
> this:
>
> NXdetector
> module01,NXdetector_module
> x[nx]
> @offset=...
> @vector= ...
> y[ny]
> @offset=...
> @vector=....
> x_data_offset
> y_data_offset
> The x any y arrays describe the pixels of the module, the offset and
> vector attributes the position and orientation in space. The indices go
> into the x,y_data_offset.
>
> Of course there are other options......
>
> What do you think? We should reach an agreement at the next telco
> latest.
>
> Best Regards,
>
> Mark Koennecke
>
>
_______________________________________________
NeXus mailing list
NeXus at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus
--
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
More information about the NeXus
mailing list