Closed dboas closed 4 months ago
Interesting, I think I’ve seen something like this before, let me search and get back to you here…
Another solution is to do nothing.
In AtlasViewer we were projecting the 3D optode locations to the 2D unit circle and saving that in the SNIRF file for later use. But now, instead, we are not saving that 2D unit circle projection into the snirf file. We will just calculate it on the fly each time we need it. Thus, there is no need to resolve this issue. Although, maybe there is still reason to resolve this issue.
From: Rob Luke @.> Date: Tuesday, February 21, 2023 at 6:38 PM To: fNIRS/snirf @.> Cc: Boas, David @.>, Author @.> Subject: Re: [fNIRS/snirf] 2D length unit versus 3D length unit (Issue #124)
Interesting, I think I’ve seen something like this before, let me search and get back to you here…
— Reply to this email directly, view it on GitHubhttps://github.com/fNIRS/snirf/issues/124#issuecomment-1439274645, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHFCP5DKBJTM6ZTIWEFSUZLWYVNWZANCNFSM6AAAAAAU2I54C4. You are receiving this because you authored the thread.Message ID: @.***>
The SNIRF Committee agrees that no change is needed.
For large probes, it is not possible to have a 2D probe representation with accurate physical units of a curved 3D probe. The 2D positions will always be warped and thus their LengthUnit will not be accurate.
In Homer, and I suspect other software as well, we project the 3D positions onto a flat 2D unit circle as is commonly done for viewing EEG 10-20 positions, etc. We store these projected 2D positions in the probe.sourcePos2D and probe.detectorPos2D fields. But the LengthUnit is not accurate for these 2D positions.
A potential solution is to add an optional field metaDataTags.LengthUnit2D, and in addition to the standard length units of 'mm', 'cm' etc, we could allow a unit of 'UnitCircle', for instance.
What do others think about this?