[Nexus] DECTRIS again

[Watts Benjamin]

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