[Nexus] NXdetector documentation misleading?

Herbert J. Bernstein yayahjb at gmail.com
Wed May 10 11:52:45 BST 2017


Dear Colleagues,

  I agree that it would be best to clarify the handling of axis names
versus the slow to fast ordering, especially in view of the improvements in
this area provided by the adoption of the NXcansas axis conventions for
axis labeling.  We should use those conventions in NXdetector.

  Regards,
    Herbert

On Wed, May 10, 2017 at 5:45 AM, V. Armando Solé <sole at esrf.fr> wrote:

> Dear colleagues,
>
> I find unfortunate the use of X and Y to refer to dimensions.
>
> In particular in NXdetector I can read:
>
> *i*: number of detector pixels in the first (X, slowest) direction
>
> *j*: number of detector pixels in the second (Y, faster) direction
>
> In fact, images get represented the other way around and the number of
> rows correspond to the vertical direction (the Y). Furthermore since the
> default order is C order, that corresponds to Z,Y,X and not to X,Y,Z.
>
> I propose to get rid of those confusing X and Y staff. For instance:
>
> *i*: number of detector pixels in the first (slowest) dimension
>
> *j*: number of detector pixels in the second (faster) dimension
>
> However, the damage is already made with things like x_pixel_size,
> y_pixel_size,
>
> Am I right to assume that what you call x, y and eventually z in
> NXdetector has to be interpreted as dim0, dim1, dim2 in the nexus
> NXdetector context?
>
> Best,
>
> Armando
>
>
>
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20170510/1e3ec4cf/attachment.html>


More information about the NeXus mailing list