Left or Right Orientation
Michael Wehmöller
can anyone tell me, how to find the left or right side of the patient in a
single slice ?
Sure I can read tags, but how to be sure of the correct side ?
Bitmap interpretation (first pixel is left/top, last pixel is right/bottom)
?
Thankæ„€ for your help
Dee Csipo
It all depends on what is the SOP Class of the image you are reading. If the
image was generated by a cross sectional modality (CT, MR, etc) the image will
not necessarily contain the patient orientation tag (0020,0020), If the image
is not required to contain an Image Plane module it is required to contain the
patient orientation tag. If the image contains the Patient Orientation tag it
will give you the directional labels for the left and the top of the image. If
the image contains the image plane module it is safer to calculate your own
positional markers from the row and column directional cosines.
And after all the "ifs" study the patient orientation definitions in Annex E of
PS 3.3 :-).
dee
;-D
"Michael Wehmöller" wrote:
> Thank´s for your help
David Clunie
Since Patient Orientation should not (and almost never will) be present for
CT and MR images, one should ALWAYS derive it oneself.
The Image Orientation (Patient) attribute is always present and consists of
a vector for the row direction and a vector for the column direction. If these
are extracted into separate vectors, then the following code from my dicom3tools
will create a string describing the direction, largest orthogonal component
first (i.e. it will return three letters for a double oblique). It should be
obvious what is going on here:
char *
DerivedImagePlane::getOrientation(Vector3D vector)
{
char *orientation=new char[4];
char *optr = orientation;
*optr='\0';
char orientationX = vector.getX() < 0 ? 'R' : 'L';
char orientationY = vector.getY() < 0 ? 'A' : 'P';
char orientationZ = vector.getZ() < 0 ? 'F' : 'H';
double absX = fabs(vector.getX());
double absY = fabs(vector.getY());
double absZ = fabs(vector.getZ());
int i;
for (i=0; i<3; ++i) {
if (absX>.0001 && absX>absY && absX>absZ) {
*optr++=orientationX;
absX=0;
}
else if (absY>.0001 && absY>absX && absY>absZ) {
*optr++=orientationY;
absY=0;
}
else if (absZ>.0001 && absZ>absX && absZ>absY) {
*optr++=orientationZ;
absZ=0;
}
else break;
*optr='\0';
}
return orientation;
}
Hope this helps ... david
--
David A. Clunie mailto:dcl...@idt.net
Director, Medical Imaging Technologies http://idt.net/~dclunie/
Quintiles Intelligent Imaging http://www.i2image.com/
521 Plymouth Rd #115 Work 610-238-0572 Fax -0578
Plymouth Meeting PA 19462 Home 570-897-7123 Fax -5117
Philippe Marzin
For NM it is a different story. It's not rare to have no orientation info at
all. Instead it is carried in private fields, I wonder why implementors do
not use standards attributes for it.
--
Philippe Marzin
GMATEK Informatique
Gunter Zeilinger
I have removed the check for (0020,0020) Patient Orientation in NM image IOs
from our validation module, because
* till now I have not met any NM image, which contains a value for this
attribute,
* and perhaps (= according my rudimental knowledge about NM imaging) the
information can also be derived from the NM/PET Patient Orientation Module -
which is a mandory module of NM + PET IODs, but the contained attributs are only
declared of type 2.
But I agree, according the Description of (0020,0020) Patient Orientation in
Table C.7-7 GENERAL IMAGE MODULE ATTRIBUTES (PS 3.3 - 1999 Page 139):
"Patient direction of the rows and columns of the image. Required if image does
not require Image Orientation (0020,0037) and Image Position (0020,0032)."
NM Image had to contain a (0020,0020) Patient Orientation Attribute - but also
no value for it (type 2).
gunter
Philippe Marzin wrote:
--
gunter zeilinger http://www.tiani.org/private/gunter/
Tiani MedGraph http://www.tiani.org
Fischerstiege 9 Work +43-1-53669-158 Fax +43-1-53669-536
1010 Vienna, Austria Mobil +43-676-5986606
Dee Csipo
Fully agree with your statement that CTs and MRS should not contain 0020,0020, but i
have seen plenty of them with 0020,0020 set. As a matter of fact in my prior life i
was forced to include the generation of 0020,0020 from 0020,0037. Life has vied
twists :-). The gist of the message is even if you find the image orientation tag
in a cross sectional image do not trust it make your own.
Thanks for the algorithm. Do you call it once for rows and once for columns? It
looks like it gives you top and left side markers. Do you get the bottom and left by
reversing the vectors?
dee
;-D
Pohlhammer
(0020,0020) Patient Orientation must never be included in an NM image IOD.
One reason is that it usually would not make sense. NM images are
multi-frame, and the frames usually have different orientations. But most
important is the definition of Patient Orientation, which you correctly
quoted from Table C.7-7. It states that Patient Orientation (0020,0020) is
"Required if image does not require Image Orientation (0020,0037) and Image
NM IOD (they are Type 2 - required if known) the condition for including
(0020,0020) is not met and it should not be included.
Also, the NM/PET Patient Orientation Module really should not be used to
deduce image orientation either. This module describes the position of the
patient relative to the ground and relative to the acquisition system. This
does not give you enough information to deduce image orientation (unless,
perhaps, if you have a priori knowledge of the particular acquisition system
that created the image).
The only attributes that accurately describe the image orientation in an NM
image are Image Orientation (0020,0037) and Image Position (0020,0032).
Jeff Pohlhammer
Marconi Medical Systems
Gunter Zeilinger <gunter.z...@tiani.com> wrote in message
news:38835427...@tiani.com...
Philippe Marzin
There is so many types of images in NM that it is hard to make a general
answer. The image orientation can often be found in the detector info and
rarely anywhere else. The image orientation attribute makes rarely sense
except for STATIC that contains only one pixel plane.
Raw Tomo and Gated Tomo images contains multiple pixel planes from different
rotations, eventually non circular and with different distances from the
patient, so the problem is far more complex ;-)
In most Recon Tomo and Recon Gated Tomo there is no orientation info at all.
(0020,0020) could be useful here, instead most sw use private tags or naming
conventions to carry the orientation.
--
Philippe Marzin
GMATEK Informatique
----------
In article <SKvh4.797$A45....@news.corecomm.net>, "Pohlhammer"
Jeff Pohlhammer
news:<866ho1$gd0$1...@front2.grolier.fr>...
>
> There is so many types of images in NM that it is hard to make a general
> answer. The image orientation can often be found in the detector info and
> rarely anywhere else. The image orientation attribute makes rarely sense
> except for STATIC that contains only one pixel plane.
No, this is not true. There are only 8 types of images in the NM IOD.
For six of these - Static, Dynamic, Whole Body, Gated, Recon Tomo, and
Recon Gated Tomo, the orientation of any frame is determined exactly
by the Image Orientation (0020,0037). Of course, you must use the Detector
Vector (0054,0020)to access the correct Item in the Detector Information
Sequence (0054,0022) to get the correct orientation.
For the other two types, Tomo and Gated Tomo, it is a bit more tricky.
Here,
you start with the Image Orientation for the first frame from the detector.
You can then determine the orientation of any subsequent frame by applying
an additional rotation about the patient. This additional rotation is
determined
from the Start Angle (0054,0200), Angular Step (0018,1144), and the
Rotation
Direction.
For all of these image types (except the two reconstructed Tomo types) the
NM
IOD allows for multiple detectors and multiple orientations. The Patient
Orientation
attribute (0020,0020) would have to apply to all frames in the image. Since
that is not possible, the NM IOD does not include it.
>
> Raw Tomo and Gated Tomo images contains multiple pixel planes from
different
> rotations, eventually non circular and with different distances from the
> patient, so the problem is far more complex ;-)
"Non-circular" just means that the radius changes from frame to frame. This
does not affect the orientation of the frames. So, the determination of
the orientation of any frame is the same as described above.
>
> In most Recon Tomo and Recon Gated Tomo there is no orientation info at
all.
> (0020,0020) could be useful here, instead most sw use private tags or
naming
> conventions to carry the orientation.
But since Image Orientation (0020,0037)is already supposed to be included
there
was no sense in including (0020,0020) as well. You can always calculate
(0020,0020)
from (0020,0037) using a simple formula like the one recently posted by
David Clunie.
The reason that we made the orientation information Type 2 in the NM IOD
is that there were real cases in which the orientation would not be known.
However, if the orientation is known, (0020,0037) is supposed to be there.
Sincerely,
Jeff Pohlhammer
Marconi Medical Systems (formerly Picker)
NM Division
Philippe Marzin
message. I confirm that your statement is correct : the standard correctly
allows to provide the image orientation.
In practice though, for RECON TOMO and RECON GATED TOMO this information is
not coded. You can verify this with ADAC, GE Genie and even Siemens. That's
already a big part of the market. The correct orientation is coded in
private fields or in a private study ID.
For non-circular .... I just meant that working with raw images is more
complex than just computing the orientation of a plane.
Should I take for granted that Dicom images from Marconi Medical Systems
(or Picker) have the correct image orientation? That would be an excellent
news for me, as I am getting tired of all these tricks.
Where can I get Dicom conformance statements of your systems?
Dee Csipo
The use of the detector vector to identify the image position and orientation is
not explicit in the standard. I have noticed that even though the Picker images
contained several detectors for studies where the image position/orientation
changes, the standard only talks about the number of detectors as if they were
physical manifestations.
The clarification is important, It also answers questions posted by Ben Chase.
I did not feel I was at liberty to state this intended use of the detector
vector but speculated it being the only way to solve the problem for the
tomographic type studies.
You may want to shed some light behind the reason why the detector vector is not
split into a slice information and a detector vector. Considering the problem
in purely academic context the the number of detectors do not change but the
position of the patient changes in relation with the detectors. So the choice
of placing the image orientation into the detector vector is not obvious. :-)
Thanks,
dee
;-D
Philippe Marzin
The standard for NM is far from being clear and that's probably why
implementors - even partipatants to the definition of NM - do not implement
it correctly or have there own way.
I agree with you that it 's not obvious to include detector infos at all for
Reconstructed, and most have not.
But it's not clear either that the standard only talks about the number of
detectors as if they were physical manifestations. For example many cameras
have physically multiple heads. For Tomo and Gated Tomo these heads, or a
sub part of them, collaborate to make one single sequence of rotations,
exactly as if it were one logical head. In that case the reason of using
multiple heads is to reduce the total study time. The standard is clear(?)
that the image should be coded (vector of indirections) as if there were one
logical head and one sequence of rotations of this logical head. But in
practice again it's different, these type of images are coded as two
physical heads, each having their own sequence of rotations.
Another thing that is strange with NM is Query/Retrieve implementations, the
GE genie stations for example, respond to query as if an image is composed
of multiple images (two if a tomo is acquired with two physical heads, 8 for
a gated with 8 time slots), worse if you retrieve the images the result is
different from the query. Sometimes retrieving at series level returns one
single file and sometimes it returns separate files (one per gate).
"Sometimes" is observed to be one file for raw multiple files for
reconstructed. Retrieving at image level always returns separate files. The
situation is not desperate as the multiple files can be recombined by
looking at private fields ;-)
Perhaps, an independant Certification Authority providing certified labels
may be a way to "help" these implementors to implement correctly and help
the comitee to define less ambiguous standards.
Also, I think (correct me if I am wrong) that you mentioned that the image
orientation in the detector info not depends on the patient position. Could
you point me to the paragraph in the standard that say the orientation is
not expressed in the patient coordinate system? Am I misunderstanding
something or is this again observed in practice?
--
Philippe Marzin
GMATEK Informatique
----------
Dee Csipo
It took me a long while to unconfuse myself about the NM IOD when it was first
introduced years ago. Jeff Polhammer and I had the good fortune to work on
interfacing the Picker NM cameras when they first implemented the new IODs.
dee
;-D
Philippe Marzin wrote:
> Dee,
>
> The standard for NM is far from being clear and that's probably why
> implementors - even partipatants to the definition of NM - do not implement
> it correctly or have there own way.
>
> I agree with you that it 's not obvious to include detector infos at all for
> Reconstructed, and most have not.
>
> But it's not clear either that the standard only talks about the number of
> detectors as if they were physical manifestations. For example many cameras
> have physically multiple heads. For Tomo and Gated Tomo these heads, or a
> sub part of them, collaborate to make one single sequence of rotations,
> exactly as if it were one logical head. In that case the reason of using
> multiple heads is to reduce the total study time. The standard is clear(?)
> that the image should be coded (vector of indirections) as if there were one
> logical head and one sequence of rotations of this logical head. But in
> practice again it's different, these type of images are coded as two
> physical heads, each having their own sequence of rotations.
>
According to the definition form part 3. (by the way this from the 98 text, I still
have to update this system :-) But i do not believe this section has changed)
Number of Detectors (0054,0021) is the number of separate detectors which
differentiate the
frames in this image. When Image Type (0008,0008), Value 3, is RECON TOMO or RECON
GATED TOMO, then the Number of Detectors (0054,0021) shall be 1.
Note: Number of Detectors (0054,0021) does not necessarily represent the actual
number of
detectors used during data acquisition.
Example 1: In a TOMO acquisition in which frames from 2 or more detectors are
interleaved to
form one continuous set of frames, then no distinction is made between frames on the
basis of
which detector created them. In this case, the Number of Detectors (0054,0021) would
be 1.
Example 2: In a WHOLE BODY acquisition in which a single detector acquires anterior
and
posterior views in two separate passes, the Number of Detectors (0054,0021) would be
2.
Detector Vector (0054,0020) is an indexing vector. The value of the n th element of
this vector is
the detector number of the n th frame in this image, and shall have a value from 1
to Number of
Detectors (0054,0021).
Nowhere in this text it is mentioned the the detector sequence is to be used in the
manner Picker uses it. The tiny exception is the note stating using the same
detector to acquire two views in example 2. Expanding that to the more general case
of the TOMO acquisition, one can see how the detector sequence can be used for the
purpose of identifying the slice. Also remember that the only place where 20,32 and
20,37 appear in the IOD is in this sequence.
>
> Another thing that is strange with NM is Query/Retrieve implementations, the
> GE genie stations for example, respond to query as if an image is composed
> of multiple images (two if a tomo is acquired with two physical heads, 8 for
> a gated with 8 time slots), worse if you retrieve the images the result is
> different from the query. Sometimes retrieving at series level returns one
> single file and sometimes it returns separate files (one per gate).
> "Sometimes" is observed to be one file for raw multiple files for
> reconstructed. Retrieving at image level always returns separate files. The
> situation is not desperate as the multiple files can be recombined by
> looking at private fields ;-)
>
The standard is not responsible for bad implementations ;-).
>
> Perhaps, an independant Certification Authority providing certified labels
> may be a way to "help" these implementors to implement correctly and help
> the comitee to define less ambiguous standards.
I think that would be politically not feasible. There was a suggestion of a new
work group for inter vendor validation, (I do not know the status.) A policing
organization would not fly, at least not in the US.
>
>
>
> Also, I think (correct me if I am wrong) that you mentioned that the image
> orientation in the detector info not depends on the patient position. Could
> you point me to the paragraph in the standard that say the orientation is
> not expressed in the patient coordinate system? Am I misunderstanding
> something or is this again observed in practice?
>
The note simply states that from a purist stand point of view creating a "new
detector" for every position of the table and then regenerating the patient based
coordinate system of the slice for the "new detector" is not something that pops to
the top of one's mind reading the IOD definition. I made no mention of the
coordinate system being anything other than patient based. The definition of 20,32
and 20,37 does not change just because they are included in the detector segment.
Ben Chase
: Hi Jeff,
: The use of the detector vector to identify the image position and
: orientation is not explicit in the standard. I have noticed that even
: though the Picker images contained several detectors for studies where
: the image position/orientation changes, the standard only talks about
: the number of detectors as if they were physical manifestations. The
: clarification is important, It also answers questions posted by Ben
: Chase.
Actually, no I don't think it solves my problem. I could not find any
explicity statements supporting this, but it is pretty clear that
detector vector (0054 0020), number of detectors (0054 0021) and
detector information sequence (0054 0022) all go together, and the
values in the detector vector are indices into the detector
information sequence.
I don't think it is ever valid to use values in the slice vector to
index into the detector information sequence. (The purpose of this
questionable use would be to mark images in a RECON_TOMO or
RECON_GATED_TOMO with per-image information not provided otherwise.)
Which still leaves me with this problem. If you have a reconstructed
volume, and want to send it as a NM multiframe of transverse slices,
how do you specify the position of each slice along the head-foot
axis? The slice vector (0054 0080) provided by RECON_TOMO merely lets
you number them consecutively with integers.
You can solve this problem, I suppose, by splitting each image out
into a separate IOD, and say that they are all part of the same
series. (I think this works, but leaves you with the silliness of
having to label each slice with all sorts of redundant information.)
But this easy dodge breaks down (I think) when you try to apply it to
RECON_GATED_TOMO. How do you encode all that timing information in a
vanilla NM IOD? And what other vendor will expect whatever sleaze is
needed to encode this, and react in a a good way, offering to show the
slices in a cine loop?
: You may want to shed some light behind the reason why the detector
: vector is not split into a slice information and a detector vector.
: Considering the problem in purely academic context the the number of
: detectors do not change but the position of the patient changes in
: relation with the detectors. So the choice of placing the image
: orientation into the detector vector is not obvious. :-)
In fact, putting Image Orientation Patient (0020 0037) in the detector
information sequence (0054 0022) makes no sense at all, to me. Image
Orientation Patient (0020 0037) describes the relation between the
image and the patient. The camera (ie. and its detectors) doesn't
enter into it at all, from what I can tell. Perhaps it is caused by
informally linking together the detector position, and the (forward
projection) image that is acquired by the detector?
- Ben Chase
"I'm quite familiar with pseudo-code, I write it myself all the time."
- Barry Margolin
Dee Csipo
You can not describe a volume in recon tomo including slice information
because the only place you could stick the information is restricted to a
single sequence item Your only choice is to use tomo and consider every
table position and/or gantry tilt as a new detector. The note in the
detector sequence description permits this.
To get a better clarification how it is supposed to work we should drag
someone in with a bit more history on the subject (Jeff, David? any takers?)
See more notes below....
dee
;-D
Ben Chase wrote:
> Dee Csipo <dcs...@charm.net> wrote:
> : Hi Jeff,
>
> : The use of the detector vector to identify the image position and
> : orientation is not explicit in the standard. I have noticed that even
> : though the Picker images contained several detectors for studies where
> : the image position/orientation changes, the standard only talks about
> : the number of detectors as if they were physical manifestations. The
> : clarification is important, It also answers questions posted by Ben
> : Chase.
>
> Actually, no I don't think it solves my problem. I could not find any
> explicity statements supporting this, but it is pretty clear that
> detector vector (0054 0020), number of detectors (0054 0021) and
> detector information sequence (0054 0022) all go together, and the
> values in the detector vector are indices into the detector
> information sequence.
You would define as many entries in the vector table as there are table
positions or gantry tilts in the study. then you would assign the items to
the slice you are describing in the spatial coordinate system. I.E. your
first slice would be the first item in the detector vector and in the
detector sequence the nth slice would correspond to the nth vector and
sequence. The detector vector is independent of the slice vector.
>
>
> I don't think it is ever valid to use values in the slice vector to
> index into the detector information sequence. (The purpose of this
> questionable use would be to mark images in a RECON_TOMO or
> RECON_GATED_TOMO with per-image information not provided otherwise.)
You would not use the slice vector to index the detector sequence. You
would use the detector vector. The vector has no other meaning than the
slice uses the nth sequence item in the detector sequence. It has nothing
to do with the slice number. In a sense i could have the first three slices
all point to the first item in the detector sequence. i.e. they are in the
same plane but number them 1.2.3.
>
>
> Which still leaves me with this problem. If you have a reconstructed
> volume, and want to send it as a NM multiframe of transverse slices,
> how do you specify the position of each slice along the head-foot
> axis? The slice vector (0054 0080) provided by RECON_TOMO merely lets
> you number them consecutively with integers.
>
> You can solve this problem, I suppose, by splitting each image out
> into a separate IOD, and say that they are all part of the same
> series. (I think this works, but leaves you with the silliness of
> having to label each slice with all sorts of redundant information.)
>
That was not the intent of the definition of the NM IOD. The fact that you
are having difficulties figuring this out gives me concern, either that the
standard is wrong or it is not clear, and i cast my vote with the later, for
one because I lack the domain specific knowledge of NM and second I trust
that the people who did the standards work were the experts. Also this is
the second iteration of the NM IOD
Lets figure out if we need to add clarifications to the text without
changing the content or the intent. (You can always write a CP)
I would argue that the standard considered all the problems you are trying
to address. The mapping between your local nomenclature/model and the
standard may not be obvious but it must exist. Others have scrutinized this
text and voted for it, that does not mean that there are no missing
details or lack of clarity, but what you placing in front of the group is
fundamental.
>
> But this easy dodge breaks down (I think) when you try to apply it to
> RECON_GATED_TOMO. How do you encode all that timing information in a
> vanilla NM IOD? And what other vendor will expect whatever sleaze is
> needed to encode this, and react in a a good way, offering to show the
> slices in a cine loop?
>
> : You may want to shed some light behind the reason why the detector
> : vector is not split into a slice information and a detector vector.
> : Considering the problem in purely academic context the the number of
> : detectors do not change but the position of the patient changes in
> : relation with the detectors. So the choice of placing the image
> : orientation into the detector vector is not obvious. :-)
>
> In fact, putting Image Orientation Patient (0020 0037) in the detector
> information sequence (0054 0022) makes no sense at all, to me. Image
> Orientation Patient (0020 0037) describes the relation between the
> image and the patient. The camera (ie. and its detectors) doesn't
> enter into it at all, from what I can tell. Perhaps it is caused by
> informally linking together the detector position, and the (forward
> projection) image that is acquired by the detector?
It all depends on how you define the meaning of a detector. (Your last
extrapolation concerning forward projections is beyond my limited knowledge
of NM image generation and procedures. I just read this stuff do not make
it :-).)
Jeff Pohlhammer
This discussion has run through several several topics. Maybe I can help
clear a couple
of things up. The following is, of course, only my opinion.
First, the original question was about how to encode a set of parallel
frames that were
created as a result of reconstructing some tomographic projection data. This
is something
that is quite common in NM, and the NM IOD most certainly does support it.
The Image Type for such data is RECON TOMO (or RECON GATED TOMO in the case
of cardiac gated data). All pixel data for all the frames is included in one
object. The order
of the frames stored in the pixel data (7fe0,0010) is given by the slice
vector (0054,0080).
The IOD definition says that the Detector Information Sequence (0054,0022)
must be
included, and that it must contain exactly one Item. Since there is only one
Item in the
Detector Information Sequence, it applies to every frame in the object.
Included in the Detector Information Sequence is the Image Orientation
(Patient) attribute,
(0020,0037). Therefore, the Image Orientation must also apply to every frame
in this
object (which is what we want!). The NM IOD does not alter the definition of
(0020,0037).
So Image Orientation (0020,0037) is defined as in section C.7.6.2.1.1, which
means that
it tells the orientation (relative to the patient) of every frame in this
object.
Similarly, the Image Position gives a position for the first pixel of the
first frame stored
in Pixel Data (7fe0,0010).
So, now you know the orientation of every frame in the object, and the
position of one frame.
So the only other information you need is the distance and direction from
one frame to the next. This is given by the Spacing Between Slices
(0018,0088), which is part of the NM Reconstruction Module.
Here is a simple example of a RECON TOMO object that contains 29 frames:
[0008,0008] Image Type:DERIVED\PRIMARY\RECON TOMO\EMISSION
[0008,0060] Modality: NM
[0018,0088] Spacing Between Slices: -4.6
[0028,0008] Number of Frames: 29
[0028,0009] Frame Increment Pointer: [0054,0080]
[0054,0021] Number of Detectors: 1
[0054,0022] Detector Information Sequen
[fffe,e000] Item
[0020,0032] Image Position (Patient) 0\0\0
[0020,0037] Image Orientation (Patient) 1\0\0\0\1\0
[fffe,e00d] Item Delimitation Item
[fffe,e0dd] Sequence Delimitation Item
[0054,0080] Slice Vector:
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23
24,25,26,27,28,29
[0054,0081] Number of Slices: 29
I hope this helps clarify the original question.
Some other things that came up in the discussion:
1) The Detectors in the NM IOD most certainly are 'logical' detectors. This
is explained in section C.8.4.8.1.3.
2) Why is the orientation information in the Detector sequence? Because the
orientation of the original projection images is directly related to the
orientation of the detector face when the image is acquired. So, there was a
choice of how to handle the case where the detector changes positions -
either define some orientation vector, or define a new 'logical' detector.
The choice was that you define a new logical detector, with a new
orientation. This works well for things like the WHOLE BODY image type, in
which it is typical to acquire one anterior and one posterior view. By
defining this as two logical detectors (with two different positions) the
resulting image has the same structure whether it was acquired on an
acquisition system that has one physical detector that is moved to two
different positions, or two physical detectors that acquire the two views
simultaneously.
For Tomographic acquisitions, manufacturers have traditionally described the
resulting frames in terms of a starting position, and then a number of
subsequent frames where the acquisition system is rotated some number of
degrees before (or during) acquiring each frame. This paradigm was preserved
in the NM IOD. See the NM TOMO Acquisition Module. It includes such things
as the Start Angle, the Angular Step, and the Rotation Direction.
So, in the Tomo case, the detector sequence gives the orientation of the
first frame of one rotational group. The above additional attributes should
be enough information to compute the orientation of the other frames.
3) Section C.8.4.8.1.3 is also very clear about the use of logical detectors
in the TOMO case. It does not matter if one detector acquires 30 frames,
each one 3 degrees apart, or if two detectors each acquire 15 frames at 3
degree spacings. If the entire set of frames are to be processed as if they
are one continuous arc of 180 degrees (30 * 3 degrees), then they are to be
encoded as coming from one logical detector (and from the same rotation, for
that matter).
4) Philippe Marzin wrote:
............................................................................
......................................
> Another thing that is strange with NM is Query/Retrieve implementations,
the
GE genie stations for example, respond to query as if an image is composed
of multiple images (two if a tomo is acquired with two physical heads, 8 for
a gated with 8 time slots), worse if you retrieve the images the result is
different from the query. Sometimes retrieving at series level returns one
single file and sometimes it returns separate files (one per gate).
"Sometimes" is observed to be one file for raw multiple files for
reconstructed. Retrieving at image level always returns separate files. The
situation is not desperate as the multiple files can be recombined by
looking at private fields ;-)
............................................................................
.....................................
I have not experienced this, so I can't comment on what GE is doing. But,
the standard is clear: Section C.8.4 states that if frames are placed in
separate SOP Instances, there can be no expectation that a receiver can put
them back together. So, if, in the above example, the Genie sends 8 image
objects, each containing the frames from one of eight time slots, then they
must assume that the receiving system will not be able to process these as a
gated TOMO.
Stated another way: ALL frames from a gated tomo acquistion MUST be in the
same NM object, or they will not be able to be processed together. Further,
as Philippe points out, there isn't enough information in the separate
objects to put them back together even if you wanted to.
5) A couple of the frame indexing vectors do not have associated sequence
attributes. This is not because the IOD definition was not completed. It is
because, as Dee stated, there was no additional information that changed
from one frame to the next.
I hope this helps.