[Nexus] DECTRIS again

Thu Oct 18 16:06:03 BST 2012

Hi,

I'm with Ben on the critique of the "exposure_time".

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.

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

-- 
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