[Insight-users] native function returning an itk::Image
namgyun Lee
ggang56 at gmail.com
Mon Sep 1 01:58:26 EDT 2008
On Sun, Aug 31, 2008 at 10:56 PM, namgyun Lee <ggang56 at gmail.com> wrote:
> I have a further question about this.
>
> Let me describe the situation briefly.
>
> I have defined all types in the header file of class and also defined a
> private member variable "list" as std::vector<ImageType::Pointer>.
> And I return the ImageType::Pointer to the "list" using two different
> methods,
>
> 1) list.push_back(this->readImg("brain.dcm"));
> 2)ImageType::Pointer myImage = this->readImg("brain.dcm");
> list.push_back(myImage);
>
> My question is what is the difference between the methods describe above?
> Could you explain the difference emphasizing the scope and reference
> counting perspective?
>
>
> Thank you so much.
>
> Sincerely,
> Namgyun Lee
>
>
>
>
> On Sun, Aug 31, 2008 at 7:56 AM, Luis Ibanez <luis.ibanez at kitware.com>wrote:
>
>>
>> Hi Protein,
>>
>>
>> In order to keep an ITK image alive when returning it from
>> a function, you *MUST* return it as a SmartPointer.
>>
>> Instead of your current signature:
>>
>> ImageType* readImg(char* imageFileName);
>>
>> You should use
>>
>> ImageType::Pointer readImg(char* imageFileName);
>>
>>
>> In that way the smart pointer will be copied in the stack when
>> the function is returning, and that temporary copy wil keep the
>> image alive long enough to survive the destruction of data in
>> the local scope of the function.
>>
>> Make sure that the returned variable is assigned to a
>> SmartPointer as well.
>>
>>
>> That is, when you call the function do something like:
>>
>> ImageType::Pointer myImage = readImg("brain.dcm");
>>
>>
>> NOTE: You *do not* need, and you *should not* modify the
>> reference counting of ITK images. SmartPointers
>> are supposed to do that for you.
>>
>>
>>
>> Regards,
>>
>>
>> Luis
>>
>>
>> ---------------
>>
>> protein wrote:
>>
>>> Hey all,
>>>
>>> This might be a duplicated question but I really didn't find a answer..
>>>
>>> Basically my scenario could be described as to write a native function
>>> to read a .png file, using an instantiated itk::ImageFileReader<unsigned
>>> char>,
>>> and return an itk::Image<unsigned char>. How to keep that itk::Image
>>> alive
>>> after returning from the native function?
>>>
>>> So in the header file I defined:
>>>
>>> const unsigned int Dimension = 2;
>>> typedef float PixelType;
>>> typedef itk::Image< PixelType, Dimension > ImageType;
>>> typedef itk::ImageFileReader< ImageType > ImageReaderType;
>>>
>>> then I declear a function, which takes
>>> char* imageFileName as input
>>> and
>>> output an ImageType*
>>>
>>> ImageType* readImg(char* imageFileName);
>>>
>>> the definition readImg function:
>>> ImageReaderType reader = ImageReaderType::New();
>>> reader->SetFileName(imageFileName);
>>> reader->Update();
>>> return reader->GetOutput();
>>>
>>>
>>> But when calling this function in main(), by:
>>> ImageType::Pointer img = readImg("test.png");
>>>
>>> I know the reader is destructed when going back to main, thus the
>>> there will be error.
>>>
>>> So I increased the reference count of reader before returning,
>>> to keep it alive even after returned from the readImg function, I added:
>>> reader->SetReferenceCount(1+reader->GetReferenceCount());
>>> before "return reader->GetOutput();"
>>>
>>> Then in the main, I could use the img.
>>>
>>> However this seems not that nice to me since reader won't get
>>> released....
>>>
>>>
>>> Could anyone tell me in general how to deal with such kind of problems?
>>> I really appreciate that!
>>>
>>> Thanks,
>>> Yi
>>> _______________________________________________
>>> Insight-users mailing list
>>> Insight-users at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20080831/c03734cf/attachment.htm>
More information about the Insight-users
mailing list