JC,

This is a bug that I would want to get fixed. Can you tell me the name of the program that does this?

Hans

In Slicer, the faulty module is: "Resize Image (BRAINS)".
As stated in a) and f), the problem also impacts other modules ("Resample Image", ...)

I think to make sure that everybody understand the problem, and agrees on the definition of the different important terms here, some small drawings would be important. Indeed, is the origin of an image defined by the corner of its first voxel or by its center. Does a resampling factor of 2 means interpolating between all the existing points (eg from 10 to 19 points) or doubling the number of points (eg from 10 to 20). What is the convention for ITK? There used to be an option in ITK3 (ITK_USE_CENTERED_PIXEL_COORDINATES_CONSISTENTLY) that was dealing with centered or non-centered voxels. What is the situation in ITK4?

I agree - this is a crucial thing to agree on. Let's try to get the interested parties to sit around by a blackboard today and work out the details.

We want slicer to have the origin at the center of the voxel:

http://www.slicer.org/slicerWiki/index.php/Coordinate_systems#Image_coordinate_system

we can use the DataProbe to confirm this with data. Probably we should write some tests to confirm this stays constant through resamplings.

I agree. We should invite Brad Lowekamp as well. The sub-sampling operation has a bit of ambiguity in how you interpret what should happen to the origin. Brad has some examples that he made previously that may be useful in determining what to do.

I'd be happy to meet, but today is already pretty packed for me.

There are two things relevant here:

a) Where is the origin? In Slicer 4, DICOM [2], and apparently ITK, the origin is in the voxel center (on the sampling point), while in MeVisLab, it is at the voxel corner [3,4].

[2] http://nipy.org/nibabel/dicom/dicom_orientation.html
[3] http://www.mevislab.de/docs/2.3.1/MeVisLab/Resources/Documentation/Publish/SDK/GettingStarted/ch11s03.html
[4] http://www.mevislab.de/docs/2.3.1/FMEwork/ReleaseMeVis/Documentation/Publish/ModuleReference/itkImageFileReader.html

b) Where is the interpolated image sampled? If the sampling grid is given, there is no ambiguity, but if you just give a resampling factor / changed spacing, the main question is whether you make the outermost new sampling points coincide with the outermost old sampling (which makes most sense from an interpolation and data loss prevention perspective), or whether you want the outermost voxel /sides/ to stay the same (i.e. "the area covered by the voxels should not change".

Ideally, everybody would accept that the outermost voxels are displayed with a different (smaller) size, then we would only have to interpolate between sampling points.

(This is also related to the big, religious discussion about what a voxel is - is it a box? a point? something in between? There is no unique answer to that and I don't want to get this discussion started here.)

Now back to the bug report: The origin should not change, if it denotes the voxel center, and the new resampling grid is "sane". With "sane" I mean that if the voxel spacing is decreased by an integer factor, the old sampling points (and thus their values, since we're interpolating them) will be retained. This is highly desirable, because that means that even with linear interpolation, there is no information loss.

On the other hand, that means that the new image size is not an integer multiple of the old one, but e.g. new_width = (old_width - 1) factor + 1. In other words, reducing the spacing by a factor of two would turn a (128x128) image into a (255x255) one. That's good, but often unexpected to people who did not think about this (cf. the "Ideally, everybody would accept..." sentence). ()

(*) Do you remember this math question from school? "Bert is building a fence along the street with 12 posts that he puts 10m apart each. How long is the fence?" (OK, it might've been 30feet each for you. ;-) )

@hjmjohnson: Do you think the steps reported by Julien leads to a valid result ? If not, it should probably be investigated. If not time for 4.3 release, let me know and we will re-target. Thanks

I talked this over with Julien and then with Jim and here is where we stand:

1) The Resample Scalar Volume module uses the input origin as the output origin.
This means that the output sampling grid is shifted with respect to the input sampling grid.
This can be seen in the attached image MRHead-first resampled to 10mm then that resampled to 1mm.png.
This was produced by:
a) download MRHead
b) resample with 10mm spacing
c) resample with 1m spacing
By cross fading between b and c you can see that the head does not move, but the border pixels change.
You can also see the difference the size of the image sampling region by making the slices visible in 3D.

2) Based on this experiment, I would say that both the ITK resampler and the slicer visualization
pipelines are correctly handling the data according to the given spacing and origin.

3) The Resample Scalar Volume module should arguably be changed to adjust the origin of the
resampling grid so that all three of these versions of the image would have the same geometric
extents in 3D.

4) This is unlikely to be an issue in practice because the correct thing to do would be to use
a reference volume to define the output sampling grid, which can be done in the other resampling
modules. I would argue that it's hard to imagine a situation where you would expect pixel level
alignment after changing the spacing of volumes that had different initial spacings,
because they probably had different origins too. If you do care
about pixel alignment then you probably want to use a reference volume to control origin, spacing,
and directions.

5) The sample data that Julien provided (18991230_010000s098a098.nii) is an odd special case
because the image is of type short and contains only the values of 0 and -1. With linear interpolation
the resampled volume appears to grow with respect to the input. But this is due to the truncation when
the values between -1 and 0 are cast back to short (it appears they are not rounded).
If I cast his volume to float first, and then run the upsampling from 1mm spacing to 10mm spacing the
image is unchanged.

I changed the priority to low.

Unless someone disagrees with my point four above I will take this off the 4.3 target list.

3) How about adding a boolean option to conditionally adjust the origin ?

4&5) The issue originally happened when trying to upsample a labelmap (with no underlying scan)

If no reference volume is provided, I would suggest to adjust the origin. That way no boolean would be required.

Pros: Simple

Cons: break backward compatibility

I agree with JC; that would be a clear bug fix and backwards compatibility should not be a real issue here.

(The alternative could've been to change the definition of the resampling grid such that the origin stays the same, but that would be much more invasive, i.e. change the image data.)

I also agree with Steve's point 4; in practice, most users will resample to a given image's grid. Nevertheless, there is the case of initial upsampling, e.g. for better accuracy.

This issue has been extensively reviewed. Several proposals were made to address specific use cases by individuals, but no implementation has been provided.

I'd be happy to review and accept patches that address an individuals concerns, but I do not have resources to attempt to add features for which I do not have testable use cases.

Reference data and further information requested but not provided. We do not have necessary information. Closing stale issue.