Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure affine attribute in sync with header after init. #688

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

takhs91
Copy link

@takhs91 takhs91 commented Nov 2, 2018

Hi,
I made the following changes that ensure that the affine attribute is in sync with the header after initializing a Nifti Image.

Those two may differ because the affine provided may contain values that need float64 to store, while they have to be casted to float32 for the nifti1 header and thus some values are slightly changed.

I actually encountered this while using as_closest_canonical (which actually creates a new instance) on images and then expecting the affine I had in memory to be the same as the one that will be written and later read from file.

I found some related issues such as http:https://nipy.org/nibabel/devel/modified_images.html and
#669 but they deal with the more general issue of memory/file mismatch that may happen while modifying things on the instance.

This is a more fundamental step that ensures the affine attribute just after init is the same as the one that will be written excluding later modifications

@takhs91
Copy link
Author

takhs91 commented Feb 11, 2019

Any thoughts on that?

@effigies
Copy link
Member

Thanks for this. Looking at it, I have a couple things I want to consider about the order of operations. I'll try to sort out my thoughts in the next day or two. In the meantime, would you mind merging master? Also, want to have a look at the tests and see what might be causing the failure?

@effigies effigies self-assigned this Feb 12, 2019
@effigies effigies added this to the 2.4.0 milestone Feb 12, 2019
@takhs91
Copy link
Author

takhs91 commented Feb 12, 2019

Thanks for pointing out the failing tests.

The tests that fail are:

  • nibabel.tests.test_brikhead.TestAFNIImage.test_load
  • nibabel.tests.test_minc2.TestMinc2File.test_load
  • nibabel.tests.test_processing.test_resample_to_output
  • nibabel.tests.test_spaces.test_vox2out_vox

Since my changes alter the affine to float32 precision on init at NIfti1 images it seems logical for some tests comparing affines to fail.

I see two options here.

  1. Replacing Nifti1 in those tests with Nifti2. With its higher precision affine the test will have to pass
  2. Keep the Nifti1 in those tests and alter the tolerance at the equality comparisons

@effigies
Copy link
Member

effigies commented Mar 8, 2019

Okay. So now I'm less sure that this is a good approach, as this will be a pretty major violation of the historical expectation for images in memory to not fully synchronize until written to disk.

We could consider an alternative method for FileBasedImages:

class FileBasedImage:
    def as_synchronized(self):
        """Generate a copy of the image as if it had been saved to disk and reloaded"""
        ...

This would allow the programmer to explicitly choose when the constraints of the format should be enforced.

@takhs91
Copy link
Author

takhs91 commented Mar 15, 2019

That is an interesting proposition. I believe it a has a bigger implementation scope though (correct me if wrong). I was kind of aware of this expectation (read about it in other issues mostly) and also learned about it the hard way. I think it needs to be better communicated in the documentation. Except it is and I missed that of course.

@effigies
Copy link
Member

At least for Nifti1Images (and other single-file images), I can quickly write you a synchronizer that will keep everything in memory:

import io

def synchronize_image(img):
    bio = io.BytesIO()
    file_map = img.make_file_map({'image': bio, 'header': bio})
    img.to_file_map(file_map)
    return img.__class__.from_file_map(file_map)

So if you just need this in your own code for now, you can use that, and we can work toward a good nibabel-level solution on a longer time frame.

As to the documentation, do you have any suggestions for making these features more obvious?

@effigies effigies mentioned this pull request Mar 15, 2019
20 tasks
@effigies effigies removed this from the 2.4.0 milestone Mar 18, 2019
@takhs91
Copy link
Author

takhs91 commented Mar 22, 2019

Hi I didn't have time to look mote into that yet. I will come back to this asap

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants