This is kind of a WIP standard, right? With opening an issue to get them to at least include the original 3D positions as well? I find it very surprising they'd voluntarily reduce the information in conversion to a file type they are in the process of defining. :(

But either way if they plan to produce some files with only this information I guess we do need to figure out how to project 2D back to 3D...

I think I confused a few different issues in my description above, sorry let me try and clarify. I think I wasn't clear on the two step procedure to create this file. Step one is converting NIRX to .nirs format. Step two is converting the .nirs file to SNIRF and writing the SNIRF file to disk. We are interested mainly in step two and making sure we read back the same information that was written to disk. I used the nirx to nirs procedure for step 1 simply because that's test data we already have and can compare to to easily in the tests, but step one isn't really that meaningful as people could just use our nirx reader.

This is kind of a WIP standard, right?

The SNIRF standard is complete, the first version was released in 2019 (reference). It's currently at version 1.3 and they are about to progress the spec to draft 1.4. This raises a good point that I should make the version clear in the filename, I will rename the file in this PR to include snirf_1_3_*. Then we can include future versions and have them all clearly tested.

Some vendors already export in SNIRF format. For example, NIRX exports their NIRSport2 devices with SNIRF format and they have kindly sent me some files, but they are too large to put in for unit tests. Until everyone gets new devices that export in snirf the majority of users will use the snirf converter provided by the fnirs society, so that's what I have used here.

BIDS for NIRS is a WIP. However, SNIRF will 100% be the supported file format.

With opening an issue to get them to at least include the original 3D positions as well?

The SNIRF format does not cause the loss of location information, it is the HomerOfflineConverter provided by NIRX. I have been in contact with NIRX to discuss this issue and they will not be releasing a version that has true 3d coordinates, because homer does not support true 3d coordinates and that is the most popular software. I can simply comment out the transformation in the conversion (that's what I do for my own data sets) or I can manually code in the original locations, but I opted to keep it in to make this process reproducible.

However, I don't consider the NIRX to nirs issue a concern here. We want to add support for reading SNIRF files which is vendor agnostic. This PR is to add a simple test file with known information. How different manufacturers encode location in to their SNIRF files will vary. To start with we want to just make sure we are faithfully reading what is stored in the file, so I considered the precise coding of locations tangential. We know the location information that is in the snirf file (its printed above), we just need to ensure this is read correctly by our reader. But if you prefer I can use my hacked version of HomerOfflineConverter?

The 3D positions stored in this file aren't very meaningful, but that's not the focus of the test file. Similarly the data itself isn't meaningful (its just room noise). What I thought was important for the test file was that we know what's in it, and that we read it correctly and that the file size is not too large. I guess I opted for reproducibility over meaningful 3d locations, but happy to switch if you prefer.

But either way if they plan to produce some files with only this information I guess we do need to figure out how to project 2D back to 3D...

Yeah this is an issue with the NIRX to nirs converter, its also appears to not be a static transformation but an adaptive iterative approach per file, so I don't know if its even possible to reverse. If people want to use NIRX data with correct 3d locations then they should just use our read_raw_nirx function. Actually I have been mainly working with Hitachi files in the .nirs format and they have correct 3d positions because the Hitachi to nirs conversion doesn't transform the 3d locations.

However, I don't consider the NIRX to nirs issue a concern here. We want to add support for reading SNIRF files which is vendor agnostic. This PR is to add a simple test file with known information. How different manufacturers encode location in to their SNIRF files will vary. To start with we want to just make sure we are faithfully reading what is stored in the file, so I considered the precise coding of locations tangential. We know the location information that is in the snirf file (its printed above), we just need to ensure this is read correctly by our reader. But if you prefer I can use my hacked version of HomerOfflineConverter?

No I agree it makes sense to use the data that standard files produce.

Actually I have been mainly working with Hitachi files in the .nirs format and they have correct 3d positions because the Hitachi to nirs conversion doesn't transform the 3d locations.

Okay good to know that some of the conversion tools are non-lossy at least :)

https://github.com/mne-tools/mne-testing-data/releases/tag/0.95

Thanks!