Skip to content

Cannot work out file type of ".nii" #620

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

Closed
DimitriPapadopoulos opened this issue Apr 19, 2018 · 7 comments · Fixed by #621
Closed

Cannot work out file type of ".nii" #620

DimitriPapadopoulos opened this issue Apr 19, 2018 · 7 comments · Fixed by #621

Comments

@DimitriPapadopoulos
Copy link
Contributor

While this is a corner case, nibabel should properly load .nii. instead of raising an exception.

>>> import nibabel
>>> nibabel.load('.nii')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/nibabel/loadsave.py", line 49, in load
    filename)
nibabel.filebasedimages.ImageFileError: Cannot work out file type of ".nii"
@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Apr 19, 2018

This happens because path_maybe_image() does not recognize .nii as an image file:

>>> import nibabel
>>> nibabel.filebasedimages.FileBasedImage.path_maybe_image('.nii')
(False, None)

and in turn that's because splitext_addext() fails and outputs:

>>> nibabel.filename_parser.splitext_addext('.nii')
('.nii', '', '')

instead of:

>>> nibabel.filename_parser.splitext_addext('.nii')
('', '.nii', '')

@DimitriPapadopoulos
Copy link
Contributor Author

And finally that's because os.path.splitext() does not work as expected:

>>> os.path.splitext('.nii')
('.nii', '')

while you expect:

>>> os.path.splitext('.nii')
('', '.nii')

DimitriPapadopoulos added a commit to DimitriPapadopoulos/nibabel that referenced this issue Apr 19, 2018
os.path.splitext() does not provide the behavior we need to properly
recognize edge cases such as '.nii' as image files.

Fixes nipy#620.
@effigies
Copy link
Member

As a point of information, you can always load such a file with nibabel.Nifti1Image.from_filename. And just out of curiosity, under what circumstances are you finding a file without a name?

And finally that's because os.path.splitext() does not work as expected:

>>> os.path.splitext('.nii')
('.nii', '')

This is what I would expect. Initial dots are considered part of the filename, not an extension.

@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Apr 19, 2018

Happens with output of dcm2nii -d N -e N -p Y in some edge cases.

@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Apr 19, 2018

I know about the behavior of os.path.splitext() but I claim this is not the behavior we need in this context.

@DimitriPapadopoulos
Copy link
Contributor Author

DimitriPapadopoulos commented Apr 19, 2018

On the other hand I can understand why you wouldn't want to deviate from the standard os.path.splitext() behavior. However while I almost always agree with choices made in Python libraries, I find the choices made in os.path.splitext() arbitrary - an optional argument would be welcome to switch behavior in edge cases depending on the context.

@lanranranM
Copy link

As a point of information, you can always load such a file with nibabel.Nifti1Image.from_filename. And just out of curiosity, under what circumstances are you finding a file without a name?

And finally that's because os.path.splitext() does not work as expected:

>>> os.path.splitext('.nii')
('.nii', '')

This is what I would expect. Initial dots are considered part of the filename, not an extension.

Hello, I'm using nib.Nifti1Image.from_filename(file_path) to read the .nii.gz file. Referring another issue post, I renamed the file without .gz and the file_path without .gz. However, it's now rasing WrapStructError('Binary block is wrong size') nibabel.wrapstruct.WrapStructError: Binary block is wrong size. How can I sove it?

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 a pull request may close this issue.

3 participants