Fix incorrect DICOMSeries order

[Pandede]

Fixes #1067.
The root cause is the series order in DicomSeries.
The whole series shares the identical InstanceNumber. When DicomSeries._sort is invoked, the sorting is no longer sorted by InstanceNumber, but the filename:

# File order in local
[
  './DICOM/DICOM/ST000000/SE000001/MR000000',
  './DICOM/DICOM/ST000000/SE000001/MR000001',
  './DICOM/DICOM/ST000000/SE000001/MR000002',
  './DICOM/DICOM/ST000000/SE000001/MR000003',
  './DICOM/DICOM/ST000000/SE000001/MR000004',
  './DICOM/DICOM/ST000000/SE000001/MR000005',
  ...
]
# File order in Google Colab
[
  '/content/DICOM/DICOM/ST000000/SE000001/MR000020',
  '/content/DICOM/DICOM/ST000000/SE000001/MR000014',
  '/content/DICOM/DICOM/ST000000/SE000001/MR000015',
  '/content/DICOM/DICOM/ST000000/SE000001/MR000001',
  '/content/DICOM/DICOM/ST000000/SE000001/MR000011',
  ...
]

This makes function splitSerieIfRequired splits into 1 series in local while 8 series in Google Colab.
In summary, the series should not be sorted by filename, it should be sorted by the attribute ImagePositionPatient[2] (The z-index of the image?) in the DICOM file.

[FirefoxMetzger]

the series should not be sorted by filename, it should be sorted by the attribute ImagePositionPatient[2] (The z-index of the image?) in the DICOM file

Yep, ImagePositionPatient[2] is similar to the z-order of the image stack. It's the z-component of a reference frame that is shared by all images in a series, so if you order by that you get consistent z-ordering and if you look at the values you get information on how far the scans are apart (the spacing along Z).

The whole series shares the identical InstanceNumber. When DicomSeries._sort is invoked, the sorting is no longer sorted by InstanceNumber, but the filename

To clarify: When the InstanceNumber is identical then python will keep files in the order in which they were listed by the OS. Most OS make no guarantees about the order they return when listing a filesystem. While this typically is alphabetical (especially for single disks) it isn't always the case for distributed disks ... and apparently S3 is one example where this is not the case.

Awesome detective work @Pandede - this would have taken me quite a while to find. 🚀

[FirefoxMetzger]

LGTM