cindeem/nibabel — comment on commit c5192e8c0e89d5fbd90467b077b2b6009f44e812
File:  line 0
By cindeem:

sorry, I was out with flu..
These ids are sometimes zero or negative meaning they are - ? not present or not frames or something
correct, the mlist contains information on where the data is stored in the file, and at times the ecat file can be missing frames, or they may be misordered in terms of how they are stored in the file, so the first data chunk may NOT be the first frame collected. At other times the mlist (or matrix list) may have 6 rows, but the file may contain only one frame, and there will be zeros in the rows that do not have data.

This allows you to know how to "deal" with the data, either for format conversion or reading. I have a further algorithm that allows the correct assignment of frame number even in the case where the data is split between different files, mis-ordered etc....
I just havent had time to integrate this into the code yet....

I might have time to work on it this week, not sure when you plan to roll out new nibabel

but your above algorithm gives the correct output
eg:
{0: [1, 16842754.0],
1: [0, 16842753.0],
2: [2, 16842755.0],
3: [3, 16842756.0],
4: [4, 16842757.0],
5: [5, 16842758.0]}
first item gives order in mlist, second gives true frame order, third gives offset into file