![[IUCr Home Page]](/iucr-top/logos/iucrhome.gif)
![[CIF Home Page]](/iucr-top/logos/cifhome.gif)
![[imgCIF Home Page]](/iucr-top/logos/cbfhome.gif)
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
Copyright © International Union of Crystallography
IUCr Webmaster