[Nexus] DECTRIS again

[Mark Koennecke]

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