[Nexus] DECTRIS again
Mark Koennecke
Mark.Koennecke at psi.ch
Thu Oct 4 13:38:45 BST 2012
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
More information about the NeXus
mailing list