bunpc / atlasviewer Goto Github PK

Hello everybody,

I am trying to install AltasViewer v2.44.0 but this error appears when loading setup.bat file (see image attached).

I know that MatlabRuntime version and AtlasViewer win version do not match but I have tried to install runtime2017b to match with win version of the Atlasviewer installer and it did not work either.

Windows 11

Matlab 2023b, Matlab Runtime 2023b

Homer3 v1.80.2

AtlasViewer v2.44.0 win2017b

Thank you,

Sarai

Hello!

I would like to generate a sensitivity profile based on individual anatomy. Everything works fine until I want to run the Forward Model.
After setting the MC Parameters and clicking on 'Generate MC input' I select the 'MC app exists. try running it' option. However, then a window pops up saying 'Sorry. Couldn't execute MC applications. Please run it manually'.

This also happens when I use the default anatoma instead of individual ones. Could you please hep me out here? I am using AtlasViewer v2.42.0 in combination with MATLAB R2017b on a Windows 11 PC.

Thanks!

Using AtlasViewer v2.12.12
Attempting to perform inter-subject variability using the guidance of this link: https://openfnirs.org/wp-content/uploads/2020/05/fNIRS_workshop_day3_ProbeLocalizationError.pdf

I have 30 optodes (15 sources, 15 detectors) and 5 landmarks, however, the output of Tools -> Probe Placement Variability only displaces 20 optodes despite my loaded probe displaying all 30 optodes. Digging deeper, I see that line 63 in AtlasViewer/Probe/plotProbePlacementVariation.m sets a short separation threshold of 15mm. To analyze my probe, I've changed ssThresh to 5mm (below the shortest length channel in my probe).

1. Is there a way to have the user define the ssThresh in the GUI before running Probe Placement Variability?
2. In general, what is the reasoning behind excluding channels < 15mm? Is it assumed that the variation in optode positioning will be larger than the length of a short-separation channel (15mm) that it's not worth investigating?

Standard Deviation results show 20 optodes.

Results table showing 20 optodes

Original digitized optodes using Polhemus displaying 30 optodes and 5 landmarks

Loaded probe in AtlasViewer showing 30 optodes

Although the colorbar in the second figure (Standard Deviation Across Digitized Probes) generated by Tools -> Probe Placement Variability is scaled to the variability of the optodes, the circles don't take advantage of the full color bar.

When attempting to get the colormap [colors = colormap], this results in a 256 row vector. Therefore line 491 in Probe/plotProbePlacementVariation.m should scale to 256, not 64. Scaling to 64 results in the optode colors to be scaled to 1/4th of the color bar, incorrectly indicating that the variability is lower than expected.

Line 491 here:

Here, I intentionally added variability on one side of the head when digitizing my modules. The original code (64 based), shows very little variability in the left and right modules, despite the figure 1 (Digitized Probe Positions) clearly showing variability.

When I change Line 491 to scale to 256 (the full size of the color matrix), the colors more effectively demonstrate the increased variability and use the full colormap scale.

Hello,

The current 2.4.4.0 version could not successfully load probe from my .snirf data (see the result). I am doing a temporal scanning while all of the probe are in vertical shape and do not align with the surface. Any functions that are related my probe will result in errors like:

Error using *
Incorrect dimensions for matrix multiplication. Check that the number of columns in the first
matrix matches the number of rows in the second matrix. To operate on each element of the
matrix individually, use TIMES (.*) for elementwise multiplication.

Error in registerProbe2Head (line 21)
probe.optpos_reg = optpos*T;

Error in AtlasViewerGUI>pushbuttonRegisterProbeToSurface_Callback (line 679)
probe = registerProbe2Head(probe, headvol, refpts);

Error in gui_mainfcn (line 95)
feval(varargin{:});

Error in AtlasViewerGUI (line 19)
gui_mainfcn(gui_State, varargin{:});

Error in matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)AtlasViewerGUI('pushbuttonRegisterProbeToSurface_Callback',hObject,eventdata,guidata(hObject))

Related documentation

Error while evaluating UIControl Callback.

I am wondering is it the problem of the version or my own data.
Please check my data here if need:
https://gocuhk-my.sharepoint.com/:u:/g/personal/siqigao_cuhk_edu_hk/EX0GbQ61qkdPvrVCUY_t6hIByOZ1MtThGuDaq5Kxdx3aOQ?e=arBA3l

Atlasviewer works perfectly fine for me if I use a .nirs file + digpts file.

There is some support for reading .snirf files implemented in atlasviewer, but I'm not sure if it's really supposed to support reading of sourcePos3D, detectorPos3D, landmarkPos3D, and probe.landmarkLabels.

If point atlasviewer to a folder containing either of the .snirf files from this zip below, there is no automatic reading of the coordinates (atlasviewer does detect and read something from the file though). It's possible to force reading of the .snirf through Tools> Probe> Load in AV, but in that case the ficudials/lanmarkPos3D positions are not read in, only sourcePos3D and detectorPos3D. Note that I supplied two .snirf files, they have different landmarkLabels, and 2x12_atlasviewer_landmarknames.snirf has the same name (and order) of fiducials as digpts.txt.

Note that the combination of .snirf file and digpts.txt doesn't work either.

I'm not sure if this is expected/intended behaviour, or if there is something going wrong. As far as I can tell, the .snirf files conform to the snirf standards.

Is there a option to create a new probe in tools like older versions?
thank you!

Hello,
I am using Matlab 2017b and following Tutorial Day7 to design sources, detectors, and dummy probes.
When required to anchor the dummy probes to a label Matlab gives the following error:
"Undefined function or variable 'data'.

Error in AtlasViewerGUI>headsurf_btndwn (line 4350)
set(handles.uitable_editMLorSL,'Data',data)

Error while evaluating Patch ButtonDownFcn."

Any idea why this may happen.
This also prevents the registration of the probe to the surface

Thanks in advance