Strings that should be scalars are arrays for multiple items in all sample files

[kdarti]

snirf spec states that /nirs/aux/name strings should be stored as scalars, the same goes for each item under metadatatags
e.g

2nd dim always equals number of characters in string.

[kdarti]

Actually, it's not only strings, also for other data types there is the same issue.

[fangq]

@kdarti, these example files were produced before the SNIRF spec was fully refined and the validator was developed.

They are currently produced by a general purpose HDF5 reader/writer I wrote for matlab (EasyH5), but EasyH5 handles general data arrays, and is not particularly validating/restricting specific data types in SNIRF fields. The SNIRF-specific data types are supposed to be reinforced in the jsnirfy toolbox .

last year, I made the following commits in jsnirfy toolbox to force array-shaped strings to variable-length string (scalar type)

NeuroJSON/jsnirfy@95db007

but I did not rebuild the sample files. I just committed an updated .snirf files regenerated using the latest easyh5 and jsnirfy toolboxes. the string variables are now scalars. please verify.

[kdarti]

Thanks, all are scalars now! And thanks for the explanation about jsnirf.

Btw, to avoid making a new issue, I noticed that source and detectorlabels are implemented in this way in the .snirf sample files:

From my reading of snirf specs this seems incorrect, so probably also a result of making files before spec.

However, in the jsnirf samples it looks like this:

		"sourceLabels": [
				"S1",
				"S2",
				"S3",
				"S4"
			]

https://github.com/fNIRS/snirf-samples/blob/3a8505f19a21749bd35f37d8ac988d5e75ca1047/basic/neuro_run01.jnirs#L20805-L20810