[Insight-users] `Image Memory Management
Luis Ibanez
luis.ibanez@kitware.com
Wed, 11 Dec 2002 08:55:25 -0500
Hi David,
It seem to be reasonable to set the
boolean flag from the outside.
Could you please try something for us ?
add the following lines
itkSetMacro(ContainerManageMemory);
itkGetMacro(ContainerManageMemory);
itkBooleanMacro(ContainerManageMemory);
to the file
itkImportImageContainer.h
around line 112, where the Initialize() method
is declared.
These line will generate the methods:
void SetContainerManageMemory( bool );
bool GetContainerManageMemory();
ContainerManageMemoryOn();
ContainerManageMemoryOff();
In that way, you will have access to the boolean
flag. Please make sure that you only alter the flag
just before destroying the filter. Since the flag
is internally set by the importer in various occasions,
a premature setting of the flag may end up being
overrided by the internal logic of the importer.
Please let us know if that helps to solve
your problem. If it does, we will include this
on the repository.
Thanks
Luis
BTW a comment about one of the options you mention:
SetOutput() is not intendend to be called from the
outside of filters. The filter makes a lot of internal
preparations on the output images. Calling SetOuput()
at the wrong time will clash with those preparations.
=========================================
David Holmes wrote:
> Sorry about that--silly mail program.
>
> Luis-
>
> I appreciate your input. You are correct, I am trying
> to "hide" the itk objects. In my application, I just
> want the data array itself. Let's see if I can write
> out the pseudo code in a way that make sense:
>
>
> <template T> T* Threshold(T* in, W,H,D,LowT, HiT) {
> //W,H,D are dimension
> //LowT and HiT are thresholds
>
> //Create Image and ImageImport so I dont have to copy
> mem
> ITK_in <- Create Image Pointer
> import <- Create Image Import Container
> import->Initialize()
> import->SetImportPointer( in,W*H*D,false)
> size = {W,H,D}
> region <- Create Region
> region.SetSize(size)
> ITK_in->SetRegions(region);
> ITK_in->SetPixelContainer(import);
>
> //Setup and run filter
> myFilter <- Create Binary Filter Object
> myFilter->SetInput(ITK_in)
> myFilter ->SetLowerThreshold(LowT) and
> SetUpperThreshold(HiT)
> myFilter->Update()
>
> //Here is what I tried, but it fails -- Although I
> generate a seperate ImageImportContainer Pointer`, I
> could do this inline with the container within the
> object
>
> ITK_out = myFilter->GetOutput();
>
> outimport <- Create another import image containter
> outimport->Initialize();
> outimport->SetImportPointer(ITK_out->GetPixelContainer()->GetImportPointer(),ITK_out->GetPixelContainer()->Size(),false);
> ITK_out->SetPixelContainer(outimport);
>
> return
> ITK_out->GetPixelContainer()->GetBufferPointer()
>
> }
>
>
> As you can see, the input side of things isnt a
> problem because I can set that flag that controls the
> memory. On the output side, you can see there is a
> problem. My code attempted to change the flag by
> passing the container back to the object through the
> SetImportPointer(). If you use the Print() statement
> before and after, the only change that you will
> observe is that the memory manage flag changes from
> true to false. However, upon exiting the function,
> the array is deleted. Not sure if that is a bug or
> how it is suppose to be. Proir to destructing all of
> the objects, the data is there.
>
> Although I would very much appreciate any additional
> help that you may be able to give, I see only a few
> options:
>
> (1) Predefine and allocate the output data array.
> Then I can use the SetOutput() method for the
> function. There are three problems that I see. First
> of all, am I certain that all of the filters (or other
> tools in ITK) support the SetOutput() method? Second,
> SetOutput() is slated to be removed from the library.
> Third, what if the filter needs to change the data
> array size? Is that re-allocated and I can check it
> after the fact, or is there a problem with this?
>
> (2) Simply copy the memory after the filter runs.
> Although memcpy seems like it would be slow and double
> the memory requirements, it does avoid my problem.
>
> Well, there you go, everything you didn't want to
> hear. Like I said, I'd appreciate any thoughts that
> you may have.
>
> Thanks
>
> david
>
>