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

[Bill Lorensen]

Mario,

What do you expect to do with the "z spacing" value since you are only
using a single slice?


On Mon, Apr 26, 2010 at 4:26 AM, Mario Ceresa <mrceresa at gmail.com> wrote:
> Hello Xiaofeng!
> thanks for your mail: I don't specify any tolerance value, at least directly.
>
> At the moment I use gdcm as compiled in itk, or by its own example
> program, not directly.
>
> Mario
>
>
>
>
>
> On 23 April 2010 17:35, Xiaofeng Z <xf10036 at hotmail.com> wrote:
>> Hi, Mario,
>>
>> Did you give a tolerance to z-spacing when you do IPPSort?
>>
>> In my experience, this is the source of sort failure in the most of times.
>>
>> Xiaofeng
>>
>> --------------------------------------------------
>> From: "Mario Ceresa" <mrceresa at gmail.com>
>> Sent: Friday, April 23, 2010 4:16 AM
>> To: "Luis Ibanez" <luis.ibanez at kitware.com>
>> Cc: <insight-users at itk.org>
>> Subject: Re: [Insight-users] How to calculate volume of an image
>>
>>> 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
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>> http://www.kitware.com/products/protraining.html
>>>>>
>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>>
>>>>
>>> _____________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.html
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>