Johann Benerradi

Hi @jeanbaptiste-billaud, Just came across this issue by doing a search for Artinis support in MNE. Hopefully you managed to solve your issue already. I had issues with non-supported fNIRS...

Yes I should have specified, the default is `RdBu_r` indeed, however I was think about it more in the the case where we would use `mpl.cm.Oranges` and `mpl.cm.Blues_r` as in...

Actually, thinking more about it, and after checking NIRS-toolbox, I feel like `RdBu_r` is probably the best way to use this function, because forcing colours for HbO and HbR could...

Closing because the behaviour makes sense

Hi @Edouard2laire! Yes this is correct, the validator is already checking this. And I saw you also created a PR to prevent some warnings that shouldn't happen, which is great!...

So you're suggesting to turn the [`/nirs(i)/probe/coordinateSystem`](https://github.com/fNIRS/snirf/blob/master/snirf_specification.md#nirsiprobecoordinatesystem) or [`/nirs(i)/probe/landmarkPos3D`](https://github.com/fNIRS/snirf/blob/master/snirf_specification.md#nirsiprobelandmarkpos3d) (which are currently optional) into a required field if 3D positions are present? Could 3D distances simply be used by some...

Sure, I guess I was more thinking in the case where it's made required in snirf specs, and therefore snirf-loading libraries make it impossible to load files that don't have...

I can work on the PR

Hi @samuelpowell @dboas, We met with the maintainers yesterday to chat about issues. It seems this issue would require a change in the validator as currently it's only possible to...

Also related to this, I think that nothing prevents from having for example only sourcePos3D and detectorPos2D (i.e. one is 2D and the other 3D) based on current notations, could...