Set start index to zeros after padImageFilter

Beginner Questions
1

Hello,

What’s the best way to set the start index (of the largest possible region) of the padImageFilter output image to zeros?

I do not allow negative indices in my application, but am noticing that the start index of a padImageFilter output image can be negative. I’d like to maintain a start index of (0, 0, …) for all images in my application. What’s the best way to achieve this while maintaining consistency within ITK, and registration of padImageFilter output image with the input image in the physical coordinate system? Should I apply the following operations on the padImageFilter output?

SetLargestPossibleRegion(region with index=zero, and size=total size of padImageFilter output)
SetOrigin(physical coordinate of the start index of the padImageFilter output)

Or, should I apply another filter, like ChangeInformationImageFilter or RegionOfInterestImageFilter, to the padImageFilter output?

Thanks,
–Fijoy

2

Here is some code which help maintains a 0 starting index in SimpleITK:

edit:

This is a procedural approach. A pipeline approach could be done too, but with your suggestions you’ll have to run padFilter->UpdateOutputInformation(), look at the image’s meta-data describing physical space ( similar to above ), then apply the appropirate parameter to one of the above filters. Or you could write a new filter to do the same by overloading the GenerateOutputInformation method.

1 Like
3

I had the same requirement for FFT padding, and created this new filter in a external module:

It overloads GenerateInputRequestedRegion, GenerateOutputInformation(), and GenerateData(), but re-using the FFTPadImageFilter.h

1 Like
4

@phcerdan At an initial look, the usage of the ChangeInformationFilter there ( in a mini-pipeline) is odd. The output image should already have the proper meta-data, from a properly implemented GenerateOutputInformation method. A simple graft of the output of the FFTPad to the output of your filter should suffice. Unless the size of the output image from the FFTPad does not match what is expected form your filters 'GenerateOutptuInformaiton`. That is some tricky stuff to get consistent a, so checks may be needed.

I’d suggest a separate filter derived from the “InPlaceImageFitler” to do this zero-index fix up. It would avoid the problem of duplicating the GenerateOutputInformation seen above when using a mini-pipeline. If you would like a more detailed suggestion please let me know.

1 Like
5

That is this case, I went to the route I was more familiar with, but I will test the grafting of the data instead of the ChangeInformationFilter as you suggested.

That sounds good, you should put it in!

1 Like
6

Here is the example which does a “proper” mini-pipeline with grafting:

The Input should also be grafted, and the output grafted to the output of the last filter in the mini-pipeline then back to the output. This isolates the mini-pipeline, as your implementation pipeline operations escape the internal mini-pipeline. The worse case of this case case input filter to re-execute and data to be re-read. The output is double grafted so that the output buffer may be reused, while preserving the generated meta-data.

1 Like