<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
With the old itm dicom reader (gdcm 1.2), the value returned by
File::GetZSpacing() was computed using an ACR-NEMA heuristics (using
0018 0050 Slice Thickness and 0018 0088 Spacing Between Slices). <br>
It was known as giving sometimes unaccurate results.<br>
<br>
The only way to be sure to get an accurate result was to use
SerieHelper::GetZSpacing() -based on Jolinda Smith's algorithm, to
order the images according to their Image Position (Patient)-<br>
<br>
I'm not aware enough on gdcm2 to tell how to do thru ITK, but, sure the
problem is solved using Serie information, and *cannot* be solved using
a single slice.<br>
<br>
--> Mathieu, -as soon as Eyjafjallajökull ashes release you- <big><big><strong></strong></big></big>
any comment would be very helpfull.<br>
<br>
Jean-Pierre Roux<br>
<br>
<br>
<blockquote
cite="mid:j2t93dce8f91004230116wbd2b9468ic4a35664409a4a31@mail.gmail.com"
type="cite">
<pre wrap="">Thanks, Luis, for your answer.
I think the ITK DICOM reader populates *wrongly* the spacing values:
The z spacing is always 1 for all my image set, but I'm sure that it
is not correct because the Slice Thickness tag and the number of
slices change with each scan.
Soeren Christensen, of the GDCM mail list, kindly pointed out that:
"The Thickness tag is not a reliable measure so instead the thickness is
computed from the slice locations and their distances. hence you need
more than one slice to estimate difference between them. If you get
and error, even for multiple slices, then look at image orientation
patient and image location patient tags. You can find info on how to
sort and calculate distances via a little googling and even on the
dcmtk faq I believe. There may be a problem with equidistance between
slices causing this issue. Looking at these tags should help clarify
that."
I'll try to investigate a little bit the issue, but if any has some
advice please share! :)
Thanks and regards,
Mario
On 20 April 2010 20:33, Luis Ibanez <a class="moz-txt-link-rfc2396E" href="mailto:luis.ibanez@kitware.com"><luis.ibanez@kitware.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hi Mario,
You should simply get the Spacing value from the itkImage, as
ImageType::SpacingType spacing = myImage->GetSpacing();
where
spacing[0] is the spacing along X
spacing[1] is the spacing along Y
spacing[2] is the spacing along Z
The ITK DICOM reader will populate the spacing values
for you.
Please note also that is you already have a segmented
image, you could use several of the "Label" filters in ITK
in order to compute the volume of a labeled region.
Regards,
Luis
--------------------------
On Tue, Apr 20, 2010 at 12:24 PM, Mario Ceresa <a class="moz-txt-link-rfc2396E" href="mailto:mrceresa@gmail.com"><mrceresa@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Hello everybody!
I'm completely lost on a seemingly stupid problem: how do I calculate
the physical volume of an image (3D CT scan)?
In the past I would have simply iterated over the interesting pixels
in the image, accumulated them in a variable, say m_Vol, and then:
std::cout << "Volume: " << m_VolLung*spacing[0]*spacing[1]*spacing[2]
This believing that spacing 0 and 1 came from the "Pixel Spacing" tag
of my DICOM header and spacing[2] from the "Slice Thickness" tag.
But now I have some CT scan images for which the spacing along z is
always 1 no matter what I try, while the Slice Thickness is different.
I spent a while dwelling into the ImageHelper::GetSpacingValue of the
gdcm factory but it is *really* complicated...
Moreover a kind person from the GDCM mailing list pointed me that:
"Pixel spacing is not guaranteed to be the same as slice thickness.
You can have slices that overlapped also gaps and then with the case
of helical CT the Slice Thickness does not make sense for the
reconstruction."
So know I'm not sure which is the best way to proceed, if any of you
could give me an hint I would be more than grateful!
Thanks and regards,
Mario
_____________________________________
Powered by <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>