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