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. |