Mark's and Mark's developers thoughts: 0-1 indexing

[jbpoline]

• why isn't the indexing based on the underlying format again ? [jb tentative response: because two different backends will lead to 2 different meta data json files ? yet another reason to keep backend mostly consistent nifti/gifti if possible?]
• Starting with 1 may be better because: "for 3D frames in a 4D probabilistic/devlopemental atlas the underlying data might use zero-based or one-based indexing, so it can't be right all the time, but a corresponding labeled atlas will use a one-based system for the datakeys, and never a zero-based system. So at least by adopting a one-based system we can make it more consistent between the datakeys for the labels and the frame indices."

Q: change convention to 1 indexing to get the datakeys right (most of the time ...) ?

[andrewjanke]

I normally have strong feelings regarding 0 and 1 indexing, but in the end its arbitrary and largely a measure of who still codes in C. I recall we voted on this and 0 won however if this slows adoption I'm not against 1 based indexing but we do need to choose either 0 or 1 and not support both or make it dependent upon the underlying format!

JSON doesn't define any standard on this that I know of. An array is just an ordered list of things, so it's going to be up to the language reading it to index into the array (if Python it will be 0 based). If Perl, use $[ and confuse everyone.

[markj789]

I did not want to bring up the first point in JB's post at all, so please forget that.

I did want to suggest indexing from 1. I think we will reduce confusion if we can at least have our format use the same numbers for datakeys and frame numbers in the cases where there is sequential label numbers and corresponding 4D (e.g. probabilistic) atlas files. This is true for a lot of the atlases currently shipped with FSL, and I'm sure this won't make the SPM folks unhappy! ;)

P.S. As for "a measure of who still codes in C" - isn't it now largely a measure of who codes in python?

[rdvincent]

Many anatomical labelling schemes do use a zero label (if that is what is meant by "datakey") for background ("unlabelled") voxels or vertices.

See also: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

[mhalle]

Indexing conventions of the underlying data file are what they are. We are describing how to get data from the underlying format. This metadata format shouldn't constraint anything unless we are discussing indexing of items completely within our own file. I'm not aware we are indexing anything (structures, etc) in the JSON format itself.

We've discussed that some formats may use strings as datakeys. That example in itself means that the details of the indexing have to be flexible, even more flexible than 0- or 1-based. That has the advantage of sidestepping a religious war that has already been fought by other format writers who doubtless have their own logic.

That doesn't mean you can't have a "best practices" guide that suggests one or the other.

Practically, at the SPL we use 0 for background in our atlases, and we don't use nifti, and we have funded efforts to support DICOM segmentation objects.