Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling data with 3D locations for sources and detectors #5

Open
rob-luke opened this issue Jul 7, 2020 · 2 comments
Open

Handling data with 3D locations for sources and detectors #5

rob-luke opened this issue Jul 7, 2020 · 2 comments

Comments

@rob-luke
Copy link
Member

rob-luke commented Jul 7, 2020

Hi all,

Thanks for the great package. I have been converting my data to snirf and run in to what I believe is a bug. Could you please let me know if this is an issue or if it is expected behaviour?

I have converted my data from a NIRX device to .nirs using the HomerOfflineConverter provided on the NIRX website. I then load this data using the code snippet from the README of this repo. I then save and load the data as described in the README. The .nirs data that I read has 3 dimensional locations for the source and detect positions. However, the snirf data is written as 2 dimensional data, so when I read it back I only have two of the three dimensions I started with.

I have provided a minimum working example below. The raw NIRX data I am using can be downloaded from https://osf.io/dj3eh/

nirs = load('Participant-1/NIRS-2019-11-02_002.nirs','-mat')

snirf1 = SnirfClass(nirs)
snirf1.Save('Participant-1.snirf')
snirf1.Info()

snirf2 = SnirfClass();
snirf2.Load('Participant-1.snirf');
snirf2.Info();
>> snirf1.probe.sourcePos2D
ans =

   -2.4810    1.0702    4.3366
   -6.4240    4.8954    4.8502
   -6.6257   -2.4181    4.3792
  -10.3412    1.6660    4.0343
    2.3877    1.2580    4.3585
    6.4382    5.0176    4.7415
    6.4641   -2.3230    4.6840
   10.2646    1.7367    4.1666


>> snirf2.probe.sourcePos2D
ans =

   -2.4810    1.0702         0
   -6.4240    4.8954         0
   -6.6257   -2.4181         0
  -10.3412    1.6660         0
    2.3877    1.2580         0
    6.4382    5.0176         0
    6.4641   -2.3230         0
   10.2646    1.7367         0
@dboas
Copy link

dboas commented Oct 19, 2020

@fangq or @jayd1860 or maybe Stephen, can you look at this pull request and accept it if you agree. I just talked with Rob and I think this is consistent with our idea of 2D versus 3D probe positions.

@rob-luke
Copy link
Member Author

Is there anything I can do to make this issue and pull request clearer/better? Or is there some code clash this causes that I'm unaware of? I'm happy to help work through any issues together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants