I confirm. By ignoring those non-integer indices, it left holes in the final map.
One reason why I decided to ignore them, is that their values were very close to already existing vertices numbers. If I were to round those non-integer, it would only lead to duplicating vertices numbers.
I was expecting to see those holes perhaps only on the periphery of the chunk. It turns out that they are actually spread evenly throughout the chunk.
All-in-all, this strikes me more like perhaps a buggy feature. As mentioned in my previous post, I'm surprised that a binary filter of what to show and what to hide leads to such anomalies.
I'm sorry, I could not follow what is not behaving correctly. From your description, I understand that you applied a spatial smoothing on integers and that you do not understand why this leads to non-integers. But this is obvious that a spatial smoothing using a Gaussian kernel would lead to non-integer values, so I guess your concern is different.
If you think there is a bug in one of the Brainstorm functions please describe precisely how we can reproduce the issue. Start from one of your tutorial protocol for instance, and describe precisely step-by-step how I can reproduce this erroneous behavior on my end.
Thanks
Francois
I'm sorry Francois I wasn't clear. There are many steps and motivations that I tried to include in my previous message and maybe I got the all entangled. If you allow me, I will try to explain my issue a second time, from scratch. I will skip the details that aren't relevant to the issue at hand.
When using the 'Keep only selected scouts' by right clicking a source file, I experience something strange. The source file I'm working with has only integers in the ImageGridAmp variable. When I use 'Keep only selected scouts', it seems that some of those values go through a form of interpolation, making them non-integers. Most of my ImageGridAmp values are still the initial integers, but 14/3000 are not.
From my understanding, this should not happen. There is no new projection, Brainstorm should merely cut away the section of brain I'm interested into. I took a brief look at these non-integers and a saw some of them were in the middle of the ROI (I thought that maybe the process would only alter the periphery as it cut out the piece of brain, but no).
I hope I managed to make this issue clearer. Now, if you want me to go into the "why" I'm doing this, I would gladly write a second post. If there's no easy solution to my issue, maybe we can find a way together to circumvent it completely.
Once again, thank you,
When using the 'Keep only selected scouts' by right clicking a source file
There is some confusion here. This menu "Keep only selected scouts" is available in the Scout tab, menu Scout > Edit surface > Keep only selected scouts. The corresponding code:
brainstorm3/toolbox/gui/panel_scout.m at master · brainstorm-tools/brainstorm3 · GitHub
This functions edits the cortex surface, not the associated source files. You should not try to remove vertices from a surface after estimating sources on them, do it before then compute new forward+inverse models.
You are absolutely right. I did exactly that: Scout tab, menu Scout > Edit surface > Keep only selected scouts.
But then, where I'm not sure I am doing the right thing, I right clicked the source file, Project sources > Subject > cortex_150000 | keep. The resulting file has the few unexpected interpolations.
This projection interpolates the source maps, each vertex with its nearest neighbors:
https://neuroimage.usc.edu/brainstorm/Tutorials/CoregisterSubjects
It's normal if you obtain non-integer values with this procedure.
Doesn't it project it to a sub-section of itself? Why are only 7/3000 vertices interpolated?
If it behaved the way you described, I feel like I would have potentially way more interpolated vertices.
This means less than 1% error, so I'm okay with ignoring those, but perhaps Brainstorm is not behaving the way it is supposed to?
Here are my exact steps if you want to replicate them.
- Create a source file with the vertices numbers stored in ImageGridAmp
idxMap.ImageGridAmp(:,1) = 1:length(idxMap.ImageGridAmp(:,1));
idxMap.ImageGridAmp(:,2) = idxMap.ImageGridAmp(:,1);
-
Import it to Brainstorm
Scout tab, menu Scout > Edit surface > Keep only selected scouts.
right click the source file, Project sources > Subject > cortex_150000 | keep
-
Export that new file to matlab as idxChunk
-
Find the non-integers
idxChunkNonInt = idxChunk.ImageGridAmp(rem(idxChunk.ImageGridAmp,1) ~=0);
In my case, idxChunkNonInt had a length of 7, whereas idxChunk.ImageGridAmp was long of 3847.
If you tell me that this is normal behaviour and Brainstorm is doing exactly what it is supposed to do, I'll quit pestering you with this. I think it really looks like a bug and I'm having a hard time finding the right words to describe it. I'm doing my best to help.
Thank you for your sustained support,
If you are suspicious of this interpolation function, you can try debugging it directly:
https://github.com/brainstorm-tools/brainstorm3/blob/master/toolbox/math/bst_project_sources.m#L163
First delete all the interpolation matrices (right-click on the surfaces files you work with > Remove interpolations).
Put a breakpoint at line 163 in bst_project_sources.m (click on the left of the line), then run the projection to you edited surface from the interface. When the debugger stops, execute the line and see what the output interpolation matrix is (all the values other than 1 would indicate that this is not a 1-to-1 match between source and destination vertices). I suspect that values other than one would be either very close to one (the closest vertex) or very close to zero (other "nearest neighbors"). At this point you can binarize the interpolation matrix if this what you need (using the function round for instance).
Or step into test_interp_tess2tess, and execute it line by line to understand how this is working.
You are right, once again. Those non-integers, once rounded, fit perfectly within the integer-only part of my chunk generated with
idxChunkInt = idxChunk.ImageGridAmp(rem(idxChunk.ImageGridAmp,1) ==0);
There are no duplicates. I will add a section to my pipeline that will round down those pesky non-integer.
Thank you for your help,