Crystallography Online: the website of the International Union of Crystallography

A few comments from someone not practiced in reading imgCIF axis
definitions:

1.  Why is ELEMENT_ANGLE dependent on ELEMENT_CAXIS?  If the two axes are
locally orthogonal, the value of ELEMENT_ANGLE is independent of the value
that CAXIS takes.  I would expect it to be dependent on DETECTOR_PITCH
only.  I also don't understand the reasoning in your introductory comment
where this dependence means that no offset needs to be specified for
ELEMENT_ANGLE  - surely if the detector is concentric around the sample
position the only ELEMENT_ANGLE vector that makes sense is [1,0,0] with no
offset?

2.  I agree that the _axis_rotation_origin item is a good idea.



On 8/2/07, Herbert J. Bernstein <yaya at bernstein-plus-sons.com> wrote:
>
> Dear Colleagues,
>
>    Here is a draft of a commented answer to the question
> James Hester raised about cylindrical detectors.  In
> putting this together it became clear that we really
> should add another category, AXIS_ROTATION_ORIGIN,
> to explicitly specify the direction at which a rotation
> axis at its zero setting points.
>
>    While such a new category can be avoided by careful use
> of implicit rules for the cylindrical detector
> element axes, the question comes up when dealing
> with detector pitch or goniometer chi.  I think we
> should take this opportunity to deal with the issue.
>
>    Comments, corrections and suggestions would be
> appreciated.
>
> #     This is an example of the axis setup for a cylindrical
> #     detector element.  The axis of the cylinder run parallel
> #     the the X-axis (the principal goniometer axis).  The
> #     radius of the cylinder is 573 mm.  The pixels on
> #     the surface of the cylinder are .1 mm by .1 mm.  The
> #     detector element has 2000 pixels along the direction
> #     of the cylinder axis and 4000 pixels along the
> #     circumference of a slice through the cylinder.  In
> #     other words, the detector element is a 200 mm by
> #     400 mm segment of the surface of the cylinder.
> #     The circumference of the cylinder is 2*pi*573 =
> #     3600.265181.  The means the each pixel is
> #     .1 mm by .00999926344 degrees.  If we place the
> #     origin of the detector element in the center of
> #     the pixel at the top left in terms of X and Y,
> #     i.e. half a pixel in from -1000 pixels left
> #     and 2000 pixels up, i.e. we need to start
> #     at -99.95 mm left and at 19.9935272482 degrees up.
> #
> #     In order to define the axes for this detector,
> #     specify ELEMENT_CAXIS for the cylinder axis
> #     with the [1,0,0] vector starting at an offset
> #     of [-99.95,0,0].  Then we specify ELEMENT_ANGLE
> #     for the cylinder surface angle as dependent on
> #     ELEMENT_CAXIS.  Because of the dependence, we
> #     do not specify any additional offset for the base
> #     of the ELEMENT_ANGLE axis.  Finally we specify
> #     ELEMENT_RADIUS as dependent on ELEMENT_ANGLE.
> #     We specify this axis to that it points to the
> #     center of the origin pixel when all axes are
> #     at their zero settings, i.e. when the
> #     ELEMENT_RADIUS is pointing in the direction
> #     [0,0.341913983,-0.939731253].
> #
> #     While this means of implicitly specifying the
> #     direction of the zero setting of a rotation
> #     axis, is sufficient for this case, it is only
> #     workable when a another axis is specified
> #     as dependent on a rotation axis.  To resolve
> #     the general case we propose to add a new
> #     category AXIS_ROTATION_ORIGIN to carry this
> #     information in general.
>
> loop_
> _axis.id
> _axis.type        #___
> _axis.equipment   #___\___________
> _axis.depends_on  #___|___________\____________
> _axis.vector[1]   #___|___________|____________\______________
> _axis.vector[2]   #___|___________|____________|______________\__
> _axis.vector[3]   #___|___________|____________|______________|__\__
> _axis.offset[1]   #___|___________|____________|______________|__|__\____
> _axis.offset[2]
> #___|___________|____________|______________|__|__|____\__
> _axis.offset[3]
> #___|___________|____________|______________|__|__|____|__\__
>                    #   |           |            |              |  |  |
> |  |  \
>
> ######################|###########|############|##############|##|##|####|##|##|
>   SOURCE            general     source          .              0  0  1
> .  .  .
>   GRAVITY           general     gravity         .              0 -1  0
> .  .  .
>
> ######################|###########|############|##############|##|##|####|##|##|
>                    #   |           |            |              |  |  |
> |  |  |
>   DETECTOR_Z        translation detector        .              0  0 -1
> 0  0  0
>   DETECTOR_Y        translation detector      DETECTOR_Z       0 -1  0
> 0  0  0
>   DETECTOR_PITCH    rotation    detector      DETECTOR_Y       1  0  0
> 0  0  0
>                    #   |           |            |              |  |  |
> |  |  |
>   ELEMENT_CAXIS     translation detector      DETECTOR_PITCH   1  0  0
>
> -99.95 0  0
>   ELEMENT_ANGLE     rotation    detector      ELEMENT_CAXIS    1  0  0
> 0  0  0
>   ELEMENT_RADIUS    translation detector      ELEMENT_ANGLE
>                                                       0 0.341913983 -
> 0.93973125
>
> 0  0  0
>
> ######################|###########|############|##############|##|##|####|##|##|
>
> # We explicitly specify the direction of ELEMENT_CAXIS  and
> # DETECTOR_PITCH when they are at their zero settings.  Note that
> # we do not have an implicit rotation origin from a dependent axis for
> # DETECTOR_PITCH.  We need to give it explicitly.
>
> loop_
> _axis_rotation_origin.axis_id
> _axis_rotation_origin.direction[0] #__
> _axis_rotation_origin.direction[1] #__\__________
> _axis_rotation_origin.direction[2] #__|__________\____________
>                                     #  |          |            \
> DETECTOR_PITCH                        0          0            1
> ELEMENT_ANGLE                         0          0.341913983 -0.93973125
>
>
> # We relate these axes to the pixels of data.  To do this
> # we use _array_structure_list and _array_structure_list_axis
> # grouping ELEMENT_ANGLE and ELEMENT_RADIUS into a single axis_set
> # effectively coupling them.  ELEMENT_RADIUS is set to the
> # constant value of 573 mm, and ELEMENT_ANGLE is stepped downwards
> # from the top if the detector.  Strictly speaking, we should
> # not specify both _array_structure_list_axis.angular_pitch in mm
> # and _array_structure_list_axis.angle_increment in degrees,
> # but we have done so here to to provide a consistency check.
>
> loop_
> _array_structure_list.array_id
> _array_structure_list.axis_set_id #___
> _array_structure_list.index       #___\_______
> _array_structure_list.dimension   #___|_______\___
> _array_structure_list.precedence  #___|_______|___\__
> _array_structure_list.direction   #___|_______|___|__\_____
>                                    #   |       |   |  |     \
>   image_1                        ELEMENT_CAXIS 1 2000 1 increasing
>   image_1                        ELEMENT_ANGLE 2 4000 2 increasing
>
>
> loop_
> _array_structure_list_axis.axis_set_id
> _array_structure_list_axis.axis_id                #_
> _array_structure_list_axis.displacement           #_\
> _array_structure_list_axis.displacement_increment #_|_\
> _array_structure_list_axis.angular_pitch          #_|__|__\
> _array_structure_list_axis.angle                  #_|__|__|_\_
> _array_structure_list_axis.angle_increment        #_|__|__|_|_\____
> #                     _____________________________/ _/   | | |    \
> #                    /                    __________/ ___/  | |     |
> #                    |                   /      _____/ ____/  |     |
> #                    |                   |     /      /       |     |
>   ELEMENT_CAXIS  ELEMENT_CAXIS            0     0.1   .        .     .
>   ELEMENT_ANGLE  ELEMENT_ANGLE             .     .   0.1      0
> -.00999926344
>   ELEMENT_ANGLE  ELEMENT_RADIUS         573     0     .        .     .
>
>
>
>
> At 7:05 AM -0400 8/1/07, Herbert J. Bernstein wrote:
> >Date: Wed, 1 Aug 2007 07:05:16 -0400 (EDT)
> >From: "Herbert J. Bernstein" <yaya at bernstein-plus-sons.com>
> >To: The Crystallographic Binary File and its imgCIF application to
> >image data <imgcif-l at iucr.org>
> >Subject: Re: [Imgcif-l] Cylindrical detectors
> >
> >>  Is it reasonable to use _array_structure_list_axis.angle_increment
> instead
> >>  of displacement_increment?
> >
> >Yes
> >
> >>  Note that the radius of curvature of the detector is implied by the
> offset
> >>  of the other detector axis, and once this is given the pixel
> displacement
> >>  increment can be converted to degrees.
> >
> >I suspect it would be better to use two axes for the circular section
> >of the cylinder, and another for the axis of the cylinder.  The
> >circle would then be described an angular axis coupled to
> >a radial axis.  The offset of the radial axis would then be
> >placed at the center of the circle, and the displacement
> >would give the (constant) radius of the circle.  The coupled
> >angular axis would then step through the pixels.  A third
> >axis would go along the axis of the cylinder.  I'll work
> >up a detailed example later today.
> >
> >=====================================================
> >  Herbert J. Bernstein, Professor of Computer Science
> >    Dowling College, Kramer Science Center, KSC 121
> >         Idle Hour Blvd, Oakdale, NY, 11769
> >
> >                  +1-631-244-3035
> >                  yaya at dowling.edu
> >=====================================================
> >
> >On Wed, 1 Aug 2007, James Hester wrote:
> >
> >>  I have a question relating to describing cylindrical detectors (e.g.
> >>  Debye-Scherrer camera using image plates) in imgCIF.  There appear to
> be no
> >>  examples in the 'canonical' imgCIF literature relating to such
> non-flat
> >>  detectors, let me give my best shot here - I would appreciate any
> feedback
> >>  as to the correctness of this description, particularly the
> characterisation
> >>  of the array structure axis as a detector rotation axis located at the
> >>  sample.
> >>
> >>  Is it reasonable to use _array_structure_list_axis.angle_increment
> instead
> >>  of displacement_increment?
> >>
> >>  Note that the radius of curvature of the detector is implied by the
> offset
> >>  of the other detector axis, and once this is given the pixel
> displacement
> >>  increment can be converted to degrees.
> >>
> >>  For a cylindrically curved detector located 573mm from the sample, I
> would
> >>  guess the following axis definitions:
> >>
> >>  ##########
> >>  loop_
> >>  _axis.id
> >>  _axis.type
> >>  _axis.equipment
> >>  _axis.depends_on
> >>  _axis.offset[1] _axis.offset[2] _axis.offset[3] _axis.vector[1]
> >>  _axis.vector[2] _axis.vector[3]
> >>
> >>  source       .        source       .        0 0 0   0 0 1
> >>  omega  rotation   goniometer .        0 0 0   1 0 0
> >>  det_up       .        detector     .        0 0 -573  1 0 0
> #parallel to
> >>  sample rotation axis but on surface of
> >>  det_along  rotation  detector  .        0  0 0   1 0 0     #coincident
> with
> >>  sample rotation
> >>
> >>  # the image that comes off is 2000x4000 pixels, with the fast and
> short
> >>  direction in the cylindrical z #direction:
> >>
> >>  loop_
> >>  _array_structure_list.axis_set_id
> >>  _array_structure_list.dimension
> >>  _array_structure_list.precedence
> >>
> >>  det_up   2000  1
> >>  det_along 4000 2
> >>
> >>  #vertical and horizontal pixels are 100 microns in size...
> >>
> >>  loop_
> >>  _array_structure_list_axis.axis_id
> >>  _array_structure_list_axis.displacement_increment
> >>
> >>  det_up    0.1
> >>  det_along  0.1
> >>  _______________________________________________
> >>  imgcif-l mailing list
> >>  imgcif-l at iucr.org
> >>  http://scripts.iucr.org/mailman/listinfo/imgcif-l
> >>
> >_______________________________________________
> >imgcif-l mailing list
> >imgcif-l at iucr.org
> >http://scripts.iucr.org/mailman/listinfo/imgcif-l
>
>
> --
> =====================================================
>   Herbert J. Bernstein, Professor of Computer Science
>     Dowling College, Kramer Science Center, KSC 121
>          Idle Hour Blvd, Oakdale, NY, 11769
>
>                   +1-631-244-3035
>                   yaya at dowling.edu
> =====================================================
> _______________________________________________
> imgcif-l mailing list
> imgcif-l at iucr.org
> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>