[Nexus] some questions about NXdetector_module

[Herbert J. Bernstein]

Dear Colleagues,

  1.  Keeping fast vs. slow straight is very important for processing
software to keep images from getting flipped.  Personally I have found
the fast-slow notation to be very useful in writing reliable software.

  2.  A good example of a curved detector is the Pilatus 12M at
Diamond.  What I suggest is to treat the entire detector as an
NXdetector_group, and each individual flat segment as an NXdetector,
so that each one can have a nice flat array of data.  That leaves the
NXdectector_module class to be used to describe the individual modules
within each segment.  In CBF I have the ability to specific segments
of a larger array and couple those segments to the actual detector
segments.  It might be nice to add the capability to NeXus.  HDF5
already has slabs, so it is just a matter of the NeXus semantics, not
a big programming
task.

  3.  For truly curved detectors, one needs to use the cansas axis
notation and couple multiple axes (e.g. one translational, one
rotational) to a single axis index.

  4.  For a 3-D detector, I suggest fast, mid, slow.  For the general
case I suggest, fast, second_fastest, third_fastest, ....

Regards,
    Herbert

On Wed, Jul 1, 2015 at 8:03 AM, Benjamin Watts <benjamin.watts at psi.ch> wrote:
> Hi Eugen,
>    I don't use it myself, but I think issue 2 refers to the readout of the
> detector. The pixels have to be put into some order to be streamed out of
> the detector and the fast direction would be the lines of pixels that are
> kept adjacent in the stream. I don't know if this is still needed for
> non-ancient setups.
>
> Cheers,
> Ben
>
>
> On 01/07/15 11:07, Eugen Wintersberger wrote:
>
> Hi folks
>   I am currently trying to improve the documentation of the `NXdetector`
> class. What I am actually trying to do is to compute the spatial
> location of a pixel in the laboratory frame for different experiment
> configurations. My requirement is that `NXdetector` and
> `NXdetector_module` should provide information to do this job. However,
> there are some issues we may should think about.
>
> issue 1.)
> If all transformations involved (in particular `module_offset`) are
> required to be translations, we can never deal with curved detectors
> which might be very useful. I guess it thus would make sense to replace
> `module_offset` my an instance of `NXtransformation`. The best solution
> might be to make module_offset an instance of `NXtransformation` rather
> than a field?
>
> issue 2.)
> What exactly is the content of the `fast_pixel_direction` and
> `slow_pixel_direction` field? Are this, for instance, the pixel center
> positions along a detector axis?
> As an example consider a 1D strip detector with 50um pixel size. Is
> fast_pixel_direction = [0,50,100,150,....] with units = um?
>
> issue 3.)
> If we want to handle 3D detector as well we maybe should ad a
> `medium_pixel_direction` field ;)
>
> If anyone is interested in what I am doing try the issue_412 branch in
> the git repository of the Nexus definitions. You find the new text in
> the Nexus Design section in the manual.
>
> regards
> Eugen
>
>
>
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
>
>
>
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
>