Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Imgcif-l] Fwd: Re: Cylindrical detectors

  • To: "The Crystallographic Binary File and its imgCIF application to image data" <imgcif-l@iucr.org>
  • Subject: Re: [Imgcif-l] Fwd: Re: Cylindrical detectors
  • From: "James Hester" <jamesrhester@gmail.com>
  • Date: Thu, 2 Aug 2007 15:17:32 +1000
  • In-Reply-To: <a06230907c2d6eda2694e@192.168.2.104>
  • References: <46B030BE020000C80001F2E3@hermes.dowling.edu><a06230907c2d6eda2694e@192.168.2.104>
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@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@bernstein-plus-sons.com>
> >To: The Crystallographic Binary File and its imgCIF application to
> >image data <imgcif-l@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@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@iucr.org
> >>  http://scripts.iucr.org/mailman/listinfo/imgcif-l
> >>
> >_______________________________________________
> >imgcif-l mailing list
> >imgcif-l@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@dowling.edu
> =====================================================
> _______________________________________________
> imgcif-l mailing list
> imgcif-l@iucr.org
> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>
_______________________________________________
imgcif-l mailing list
imgcif-l@iucr.org
http://scripts.iucr.org/mailman/listinfo/imgcif-l

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links