wb_command -file-information gives you stats like this: Map Minimum Maximum Mean Sample Dev % Positive %Negative Inf/NaN Map Name
On Aug 25, 2015, at 6:32 AM, Matthew George Liptrot <[email protected]> wrote: > Hi Stam, > > Yep, workbench opens them fine. If I load in the dconn file, a surface and > the greyordinates.dscalar file, then I can see the connectivity maps as I > click different parts of the surface. > Is there a better way to check if the values are reasonable? E.g. Would the > histograms report if NaNs are present? > > Good to hear about the FSL release! I guess though that this is a wb_command > bug (or a bug in my use of it! :-) > > Cheers, > > M@ > > On 24/8/15 14:40 , "Stamatios Sotiropoulos" > <[email protected]> wrote: > > Hi Matthew > > No, they are not meant to be there. Can you open and display the dconn file > in workbench? > > FYI, there will be a new FSL release sometime this or the next week. It will > have some bug fixes in probtrackx2 and some new features. It may be the case > that this problem disappears with the new version. > > Cheers > Stam > > > > On 24 Aug 2015, at 08:24, Matthew George Liptrot <[email protected]> > wrote: > >> Hi all, >> >> We’ve been using the HCP DWI data to generate dense connectomes in ‘matrix3’ >> format. Following previous advice, we are doing this in multiple stages: >> • Generate 3 separate targets (left surface, right surface, subcortical >> voxels) >> • For each, run probtrackx2 (seed = white matter voxels, target as >> above) multiple times using the ‘-rseed’ option (1000 streams per voxel as a >> robustness / computational trade-off). >> • The multiple probtrackx2 runs are combined with FSL’s >> fdt_matrix_merge. This gives us 3 FSL .dot files. >> • Convert each of the three .dot files to .dconn using <wb_command >> -probtrackx-dot-convert> >> • Merge the three .dconn files using <wb_command -cifti-merge-dense> >> to obtain the final 92K x 92K dconn matrix. >> The problem is that we get both NaN’s and zeros in the final, merged dconn >> matrix. Presumably we should not have any NaN’s, as the numbers should just >> represent count statistics? >> >> We looked into the outputs at different stages, and it seems that the NaN’s >> only appear after Step 5. >> >> So our question is: are the NaN’s meant to be there, and if so, what do they >> represent? If not, is this a bug or a mistake on our part? >> >> Many thanks for any help! >> >> M@ >> > > > -- > Matthew George Liptrot > > Department of Computer Science > University of Copenhagen > & > Section for Cognitive Systems > Department of Applied Mathematics and Computer Science > Technical University of Denmark > > http://about.me/matthewliptrot > > _______________________________________________ > HCP-Users mailing list > [email protected] > http://lists.humanconnectome.org/mailman/listinfo/hcp-users > _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
