@Mihail_Isakov I do not have any experience with or access to the tool you are using, or to its source code, and I didn’t investigate the content of those files. All I know is that if I use established open source tools that I trust, I do not see inconsistency in how images show up in Slicer. I would be very surprised if dcm2niix didn’t sort frames, and that’s what I used to load the multiframe image into Slicer.
I won’t have time to debug this any time soon. But I also won’t take a screenshot from an unknown tool as a proof that data encoding by David Clunie is incorrect
As explained in the link mentioned in the first post of this topic, Slicer is not able to properly load this multiframe directly. I used dcm2niix to make a NIfTI first, which I then loaded into Slicer. The whole reason this topic started is because Slicer cannot (at least, not always) directly and correctly load multiframe DICOM images.
The latest development version of dcm2niix allows programs like Slicer to request files for conversion. In addition, dcm2niix could also be extended to create NRRD files instead of NIfTI files. In my experience, DWIconvert is typically very robust. However, for situations like multi-frame it might be nice to have an alternative mechanism.
The simplest NRRD implementation would be to convert files very similar to NIfTI: with space being stored in the first three dimensions and the fourth used for time (fMRI) or diffusion direction (DWI). The gradient direction in NRRD seems a bit simpler than the FSL bvecs, so it seems that would be more direct.
This would take a bit of development effort, so if the Slicer community is happy with just using dcm2niix for NIfTI, I can understand.