neurosynth / nsviewer Goto Github PK

Hi there,

So, for a variety of reasons, I fooled around with creating a custom nifti1 reader in javascript, and made something that actually works, and a toy viewer to go along with it. Here's a demo:

http://njvack.github.io/jsnifti

... and the source:

https://github.com/njvack/jsnifti

It's small (minified and gzipped, the reader is about 19k) and fast -- parsing the structural image from the NIH test dataset takes about 20ms on Chrome/my 5-year-old Air if the file's endianness matches, and 500ms if it doesn't.

All the header fields are included (yay jBinary), and getting slices is easy (#ras_slice). Slicing and rendering in the (broken, unoptimized!) toy viewer is insanely fast (about 3ms/frame).

It's still missing some features (most notably, converting ijk <-> ras coordinates) but that shouldn't be too hard to add.

Anyhow! We may wind up using this internally, but it also might be useful for you.

Currently there's no option for passing a threshold to viewer.loadImages.

Might be a good idea to have the viewer load different functional layers in different colors by default. I'd fix it if i knew Coffee Script!

There's no pressing need for this feature, but I think it would be really nice to have at some point.

The basic idea is that almost all blob images collapse (possibly with complicated statistics) across some fourth dimension, whether you're plotting a subject's activations (so, time), a group map (subjects) or a metaanalysis (studies). There's a lot of information that gets lost in the blob maps that might be interesting, and there's no good way to represent it within the brain image paradigm.

But! Once you have a nice dynamic voxel picker, it's straightforward to link your statistical image to some 4D dataset that you consider "underlying" and plot the values across the last dimension at the selected voxel. In other words:

(imagine that the IPython plot is part of the viewer app and dynamically shows you the values across time/subjects/studies in the voxel that the crosshairs are centered on).

This seems like something that wouldn't be very hard to do with the existing tools + d3, so I thought I might put it on the agenda while I'm spamming the github issues.

The changes introduced in #23 rely on npm-sourced libraries called via require(). This is a good opportunity to bundle all the other dependencies properly with npm as well.

At the moment, all visible layers are independently painted to the canvas, which is hugely inefficient. Instead, we should loop once over all voxels, compute the final color image in memory, then blit to the canvas just once. This should take us from linear time in the number of layers to close to constant time, since profiling suggests that nearly all of the time is currently taken up by the painting operation.

Does nsviewer only support niftis of size 91 109 91? If so, is there chance that different image sizes will be supported in the future?

Currently there's no way to view clusters, which makes it hard to determine what's in an image. It would be nice to add an SPM-like table that displays the peaks and cluster sizes for all clusters of contiguous voxels in an image, and navigates to the peak voxel when a row is clicked on. This should ideally done dynamically (i.e., the table is updated whenever a threshold is changed).

Hello there!

Looks like there hasn't been much activity here in awhile, but I was looking to use this viewer as part of an html report generator I'm working on. Everything seems to work fine, except loading the images. When I cloned the repo and opened index.html in the example, the images wouldn't load. The spherical ROI does load, so it seems like app.js isn't finding the images. I tried using absolute paths to no avail.

Let me know if anyone has any ideas or clarifying questions, etc

Key image/layer parameters (e.g., color palettes, initial crosshair position, etc.) should be encodable in an object so settings can be easily updated (e.g., when loading a viewer with parameters encoded in the URL).

It would be good to add a progress bar when loading images; at the moment large images can take a while to load (particularly when read from binary file), and the user may wonder whether anything's happening.

Heya,

I'm wondering about your reasoning behind making Viewer a singleton class -- I can see having two synchronized views for comparison purposes.

If I made it a non-singleton, would you be sad?

Slider value isn't updating properly to reflect the actual handle position (e.g., when dragged to minimum value, some value other than 0 typically appears).

There are several versions of these palettes floating around github, and they'd be a nice addition to the current set of palettes.

Also some way of explicitly banning the "jet" colormap from ever being used would be good too...

I assume it no longer lives in Colorado, but I'm not sure where to find it.

This image https://dl.dropboxusercontent.com/u/412959/spmT_0001.nii is displayed as a scrambled matrix.

See #17 (comment)

We should switch from representing image data as arrays-of-arrays-of-arrays to 1D typed arrays, probably using ndarray. This should speed up performance considerably.

Hey Tal,

I've been looking into how to get rid of the overlap artifacts that happen with zooming and transparent layers, and I think I have a pretty good handle on it.

My plan would be to have each view have its own array of layers and its own canvas, draw the pixels directly to it (with color mapping done at this step), and then use drawImage() to blit the layer to the View's canvas.

If I were to work up a PR along these lines, would you be receptive?

It's not clear to me whether the heavy lifting here is in nsviewer or XTK, but it would be good to have.