[Insight-users] How to calculate volume of an image

[Jean-Pierre Roux]

Hi,

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).
It was known as giving sometimes unaccurate results.

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

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.

--> Mathieu, -as soon as Eyjafjallajökull ashes release you- ** any 
comment would be very helpfull.

Jean-Pierre Roux


> 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<luis.ibanez at kitware.com>  wrote:
>    
>> 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<mrceresa at gmail.com>  wrote:
>>      
>>> 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 www.kitware.com
>>>        
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100423/c36127b2/attachment-0001.htm>