Final image transformation takes long time

[orange676]

I am using elastix as a library, and want to get the affine transformation matrix. The registration works pretty good 👍 . However, the final applying of the transformation tooks really long time, which I don't understand.

I have 3D image, about 400x400x300, the registration tooks around 40sec, however, the final applying taks nearly 3min. I further add some debug code, it shows that most time is spend on elxResamplerBase::CreateItkResultImage(.) by the ResampleImageFilter. I assume during the registration, many times of resample happend, how could the last application took so long time? I also tried manually call resampleImageFilter on my image, with affine transformation, it is about 10sec. So What I see in the code , is that you have elxMyStandardResampler, wrap around itk resample image filter.
Actually, I don't need this image. I tried to set WriteResultImage to false. However, because it is running as library, I think it will create this image. I tried to false writeResultImage to false in code, then some exception will happen. what is the proper way to skip this time consuming step ?

[N-Dekker]

@orange676 Thank you for reporting this issue. Are you sure that setting WriteResultImage to false does not work for you? Because I just tried, and it seems to work, even when using elastix as library! I locally tried changing "true"to "false" as WriteResultImage parameter value in the unit test ExampleFromManualRunningElastix, at:

https://github.com/SuperElastix/elastix/blob/5.0.1/Core/Main/GTesting/ElastixLibGTest.cxx#L92

Then, when executing a Debug build, ResamplerBase<TElastix>::CreateItkResultImage(void) was no longer called while running this unit test.

You see, when elastix is used as a library, it still checks if( writeResultImage == "true" ) before creating the result image:

https://github.com/SuperElastix/elastix/blob/5.0.1/Core/ComponentBaseClasses/elxResamplerBase.hxx#L237-L243

Can you still further clarify the issue?

[N-Dekker]

@mstaring Do you have a suggestion how to further proceed with this issue? As far as I can see, the library does take the WriteResultImage parameter into account.

[mstaring]

For the first part of the question, it is normal that the resampling takes much more time than the time during registration, as during registration no resampling of the complete image is done. Only about 2000 samples are warped and interpolated.

As for the second part, Niels' response says that we are not able to reproduce this issue at the moment. @orange676, could you provide a reproducing example of this behavior? If not, I suggest to close the issue.

[orange676]

Hi Niels and Marius, thank you for taking care. I also looks at the code, but I am afraid when using it as library, there are probably multiple place to set the parametermaps. Here is how I get the parameter map

I have already set writeResultImage to false, however, it did not work. It true that no image is saved on disk, but it seems the calcualtion is still performed. In the end, I set the "ResampleInterpolator" to FinalLinearInterpolator, to make the time acceptable.
But on the other side, I also add an initial transformaparameter file, where I did not specify the writeResultImage, could that be the reason?

[N-Dekker]

@orange676 Thanks for your further elaboration on this issue. Now I see, WriteResultImage has been re-enabled explicitly, by ElastixFilter::GenerateData():

      // Elastix must always write result image to guarantee that the ITK pipeline is in a consistent state
      parameterMapVector[ parameterMapVector.size() - 1 ][ "WriteResultImage" ] = ParameterValueVectorType( 1, "true" );

https://github.com/SuperElastix/elastix/blob/5.0.1/Core/Main/elxElastixFilter.hxx#L133-L134

With commit a6e8f10 "ENH: Add ElastixFilter support for initial transform parameter file" by @kaspermarstal, 3 February 2016. Kasper do you happen to know if it is still necessary nowadays, to always to do WriteResultImage = "true"?

[orange676]

Hi Niels and Marius, Thank you for solve it :-) can I ask you another questions? About the "not enough sample" error. I had this problem in the very begining, after I provide the intial transform, this problem seems solved. But it appears from time to time, I have check my initial transforamtion, it looks not bad. I have also noticed that it fails more often if the initial rotation is large, or sometimes I need 180 degree. Can elastix handle such case or what is the proper way to handle it? Should I open another ticket for this question?

[N-Dekker]

Thank you for solve it :-)

@orange676 The issue is not yet solved! We just got an explanation of why the final image transformation takes such a long time. I'm now preparing a real fix, at https://github.com/SuperElastix/elastix/tree/GenerateData-no-longer-set-WriteResultImage-true But I still need to figure out what might go wrong when GenerateData() no longer explicitly sets "WriteResultImage"!

About the "not enough sample" error. I had this problem in the very begining, after I provide the intial transform, this problem seems solved. But it appears from time to time, I have check my initial transforamtion, it looks not bad. I have also noticed that it fails more often if the initial rotation is large, or sometimes I need 180 degree. Can elastix handle such case or what is the proper way to handle it? Should I open another ticket for this question?

This sounds like another issue to me, for which you might open another ticket (GitHub-issue)...

[N-Dekker]

@orange676 Can you please confirm that the issue (Final image transformation takes long time) is solved now at the develop branch? With commit 7d9b9ef, "PERF: GenerateData() should not set "WriteResultImage" (pull request #477).

[N-Dekker]

Closed for now, thank you @orange676 Please reopen if you think otherwise!