[Nexus] DECTRIS again

[yayahjb]

Dear Colleagues,

   This is a good idea.

   What you are think of as a "module", imgCIF thinks of as an "element",
and the default assumption is that all detectors consist of multiple 
elements,
just that some detectors have only one element.  This allows for arbitrarily
complex detector configurations.   I think you will find this approach
useful in general, not just for the DECTRIS detectors.

   Regards,
     Herbert


On 10/4/12 8:38 AM, Mark Koennecke wrote:
> 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
>