Mercurial > hg > orthanc-stone
comparison OrthancStone/Resources/Documentation/Coordinates.txt @ 1775:fca942f4b4a7
fix conversion from voxel centers to texture borders
| author | Sebastien Jodogne <s.jodogne@gmail.com> |
|---|---|
| date | Wed, 12 May 2021 19:57:50 +0200 |
| parents | |
| children | 9ab251c03eda |
comparison
equal
deleted
inserted
replaced
| 1774:95ece40bb298 | 1775:fca942f4b4a7 |
|---|---|
| 1 | |
| 2 Some notes about the coordinate systems | |
| 3 ======================================= | |
| 4 | |
| 5 * The 3D coordinates are expressed in the PATIENT system, *not* the | |
| 6 "gantry" coordinates. As a consequence, the tags "Image Position | |
| 7 Patient" (0020,0032) and "Image Orientation Patient" (0020,0037) | |
| 8 describe the 3D geometry of a slice. | |
| 9 | |
| 10 * The tag "Patient Position" (0018,5100) could be used to convert from | |
| 11 patient coordinates to gantry coordinates, but this would be useful | |
| 12 to device manufacturers, whereas Stone primarly deals with users of | |
| 13 modalities. | |
| 14 | |
| 15 * The "Image Position Patient" gives the 3D coordinates of the CENTER | |
| 16 of the voxel of slice. | |
| 17 | |
| 18 * In 2D compositors, the origin of a texture corresponds to the CORNER | |
| 19 of the texture (*not* to the center of the first pixel). Roughly | |
| 20 speaking, the operation "floor()" must be applied to move from | |
| 21 floating coordinates to pixel coordinates. | |
| 22 | |
| 23 * The classes deriving from "IVolumeSlicer" must pay to attention to | |
| 24 convert from centers of 3D voxels to bounding boxes of 2D pixels. |