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

AimsFileInfo crashes with some DICOM files #87

Open
sapetnioc opened this issue Nov 10, 2022 · 2 comments
Open

AimsFileInfo crashes with some DICOM files #87

sapetnioc opened this issue Nov 10, 2022 · 2 comments
Labels
bug Something isn't working

Comments

@sapetnioc
Copy link
Member

Describe the bug
Downloaded some DICOM from a head scan of my mother. Unzipped the archive and launches AimsFileInfowith one of the files in parameter. Got a segfault.

Environment:

  • Engine: Singularity image casa-dev-5.3-10
  • Version of BrainVISA: compiled from master branches

Additional context
Note that dcm2niix does not support the DICOM format. I have many of these errors:
Unsupported transfer syntax '1.2.840.10008.1.2.4.80' (decode with 'dcmdjpls jpg.dcm raw.dcm' or 'gdcmconv -w jpg.dcm raw.dcm', or recompile dcm2niix with JPEGLS support)

@sapetnioc sapetnioc added the bug Something isn't working label Nov 10, 2022
@denisri
Copy link
Contributor

denisri commented Nov 18, 2022

I have fixed a problem which actually caused the crash, but there are still strange things happening: in the reader (the checker actually) a vector is allocated for slices, with the number of slices as the number of elements. But then things are stored in this vector with slice position as index. In the small dataset I have, there are 3 slices, but positions are 0, 1 and 4. Thus 4 was after the end of the vector. I have added a test to resize the vector when this occurs, but I don't know how these things are used later, and it probably produces unexpected things (plus, some items in this vector thus remain unassigned and uninitialized). So: for me I can load the small dataset, it doesn't crash anymore, but I'm not sure things are OK. Moreover the 3 slices in my dataset are not in the same orientation, and now I have a volume with 3 slices of the dimensions of the 1st one - patently wrong also.
Anyway the problem in the first place is probably that these slices should not be identified as part of a single volume. Either the slices selection in the reader is wrong (but I don't know the criterions), or the image header is wrong and has the same identifier (or whatever) for slices which should be separated.
Can you retry with the full dataset ?

@denisri
Copy link
Contributor

denisri commented Jun 21, 2024

Does the fix for #109 also fix this one ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants