Keep the filenames short

[tsalo]

https://groups.google.com/forum/#!topic/bids-discussion/IdWe0R8OFyw

1. ALL parameters should be included in the JSON file, regardless of their inclusion in the filename or path, and that values in the JSON file be lists, so that they can easily accommodate 4D files when necessary. For example, flip angle would be a list that could be more flip angles.
2. The length of the filename should be restricted to be no longer than 32 characters. We can discuss the actual length, but given that we can expect a long path the proceed the filename, and need to rely on the entire file path, it should not be too long. I believe that the current max length for filenames in AFNI is 255 characters and anything beyond that gets truncated, but even if AFNI increases this value to 1024, or 102040 there will always be a max, and we need to enforce some length restriction in the spec. I also challenge the human readability of a filename that is this long.
3. That we do not add any new key value pairs to the filename other than the ones in the current standard.
4. That we allow the "-" character to occur inside values. We can then state that for a key value pair, the value before the first hyphen is the key and everything after is the value. This would accommodate Bertrand's concerns regarding subject identifiers, as well as allow the ACQ field to be overloaded to contain more key value pairs for software and users that wish to overload the ACQ tag to include more information, such as MT-ON, Echo-1, or otherwise. Software that does not support this overloaded would then just interpret the entire ACQ value as a string that points them to the correct .json file. As Chris points out, this may break some pre-existing implementations, but since it wasn't clearly defined before, we need to pin it down.

Original authors: @ccraddock

[tsalo]

@CPernet suggested:

3. That we do not add any new key value pairs to the filename other than the ones in the current standard.

3. That we do not add any new [mandatory?] key value pairs to the filename other than the ones in the current standard.

relates to a case where we want to add info about contrast agent so we have a new optional key called ce (contrast enhancement) and the value is the product used (+a description in the json file) -- see email thread with Pauline Roca

[tsalo]

@TheChymera wrote:

3. That we do not add any new [mandatory?] key value pairs to the filename other than the ones in the current standard.

I agree with this suggestion. We need to allow people to add fields. A missing field and a strict requirement thereof could be a major reason for not using the standard.

[tsalo]

Robert Welsh wrote:

I realize is comment could be here as well:

Since there are tag/value pairs actually as part of the file names, should the order even matter? that is, scripts should scan for "sub" or "task" in the name and then grab the value. That would allow for much needed flexibility in the naming. Thus, a name such as

• run-01_task-rest_sub-001.nii.gz
• run-01_sub-001_task-rest.nii.gz
• task-rest_run-01_sub-001.nii.gz
• task-rest_sub-001_run-01.nii.gz
• sub-001_run-01_task-rest.nii.gz
• sub-001_task-rest_run_01.nii.gz

would all be BIDS compliant. I would push for this type of flexibility.

[jbteves]

Tagging @afni-rickr and @leej3 : is this filename max length of 256 accurate? If so, could it be amended easily and does it include the full path, or is that a separate max length requirement?

I'm not thrilled about allowing dashes inside the labels, as I discuss in #17. However, I will say that inhumanly readable filenames can also be quite challenging and this is therefore a balancing act.

[afni-rickr]

Hi @jbteves , I think the 256 limit comes from the file system, rather than from AFNI. I cannot even "touch" a file of over that length (either on my ext4 file system, or on the gpfs file system used for the HPC cluster).
AFNI has a limit of 999 for a dataset prefix (which then might be moot), and a separate limit of over 4000 for the path to it.

[jbteves]

I see, thanks for clarification! I'd forgotten about that being a filesystem limitation.