Reset index of an image after Crop

Engineering
,
1

Dear All,

This is a very specific question so I will give some context:
I’m registering two Images with very different sizes, but the assumption (verified in script) is that the moving image is far smaller and completely contained in the fixed image.

As an initialization step I crop the fixed image around the moving image region to speed up the process and prevent MMI metric errors.

So, at this point I feed the cropped fixed image to the registration method, without success. I must specify that if I write and read the cropped fixed image (as a debug step) the registration is successful.

If I ::Print() the cropped fixed image information the only difference between the written and read back image is that the index is not placed at [0,0,0].

I’m assuming this is the problem, since the origin and all relevant other informations are correct. Do you have any suggestion on why this is happening or if there is a possible solution?

Thanks in advance for your help!

2

I guess you tried sitk::Image::SetOrigin ? BTW, you use simpleitk ? Or ITK only ?

3

Try using itk::RegionOfInterestImageFilter. It does the same operation as the Crop filter, but with different parameters and sets the starting index to 0 while recomputing the origin.

2 Likes
4

I’m using ITK in cpp.
The origin is already correct. Anyway resetting it doesn’t solve the issue unfortunately.

5

Ok I will try to implement my cropping using this filter and update you on the results! Thank you!

6

Issue solved with @blowekamp suggestion, changed the parameters given to the filter to a region with desired size and an index corresponding to the origin of the overlapping region.
Thank you!

1 Like
7

Thanks for reporting that it fixed the problem. It sounds like there is likely a bug.

To clarify your usage, you were using the ExtractImageFilter’s output as input to the ImageRegistrationMethodv4’s Fixed input?

8

Indeed! To be more specific I’m encountered the bug using CropFilterFilter, a child object of ExtractionImageFilter (didn’t mean to correct you, just wanted to be 100% sure we’re on the same page as this could be a bug).

CropFixedFilterType::Pointer CropFixedFilter = CropFixedFilterType::New();
CropFixedFilter->SetInput(Image2Crop);
CropFixedFilter->SetLowerBoundaryCropSize(LowerCrop);
CropFixedFilter->SetUpperBoundaryCropSize(UpperCrop);
CropFixedFilter->SetDirectionCollapseToIdentity();
try
{
if (verbose)
std::cout << “Cropping Fixed Image to Moving image size\n”;
CropFixedFilter->Update();
}
catch(itk::ExceptionObject &err)
{
std::cerr << “Exception caught while cropping \n”
<< err << std::endl;
return EXIT_FAILURE;
}
FixedImage = CropFixedFilter->GetOutput();

This is the extract of the code where I connect everything. Again if I save “FixedImage” and read it back, the problem doesn’t occur.

1 Like
9

Not surprising. The “starting” index is used in ITK’s image data representation to stream in the pipeline. The image file formats don’t have this notion, so the starting index of a written files is always zero. When writing the origin is adjusted so that the physical location of all pixels remains the same.

1 Like