MRG: Slice viewer #404
MRG: Slice viewer #404
Conversation
|
The one thing I'm not certain about is this change: 4815e1e#diff-4e1d219713c81bf1e72f89cb1d87d87dR369 I had to make it to comply with newer |
|
Sweet, checks passed. |
|
hehe, I feel like this guy: http://gph.is/1m6SGhP?tc=1 |
|
I think I originally wrote this about 4 years ago! :) 👍 |
|
Is there a 5 year rule for code like the 5 second rule for food?
|
|
I believe that this rebase+merge is the code equivalent of picking it up, giving it a quick look-over, blowing on it, and popping it in your mouth :) |
|
Yummy. |
|
Hi @Eric89GXL. Thanks for renewing the effort to get this into I just made a PR to your branch with a proposed enhancement to allow incrementing/decrementing the volume with the +/- keys. I have found this more convenient than having to mouse over to the fourth axis to drag the volume slider. I also modified the viewer to raise an immediate |
|
One other issue I that could potentially be addressed either here or in a future PR is the scaling of the timecourse plot that appears in the 4th axis for 4D data. In my experience, the range of the plot does not get adjusted appropriately and the timecourse ends up plotted as a nearly flat line in the display. |
|
@grlee77 IIRC the ylim is set based on the global min and max of the data, and the line reflects the values in the current voxel across volumes. So if the voxel you're on doesn't traverse a large range relative to all the voxels, this is expected behavior (to make all voxels comparable it's good to fix the ylim). |
|
I guess it is a matter of preference, but I think it would be nice to have an option to rescale to the full range for each individual voxel. As is, it seems that the line will nearly always appear flat for fMRI data where the signal changes of interest are only a small percentage of the baseline intensity. The display range will often be set to a very large range because data.min() will often be near or equal to zero due to voxels outside the object. |
|
Let's sort out the right thing to do with the scaling in a subsequent PR |
|
sure, no problem |
| self.close() | ||
| elif event.key in ["=", '+']: | ||
| # increment volume index | ||
| new_idx = min(self._data_idx[3]+1, self.n_volumes) |
There was a problem hiding this comment.
Spaces around the -. And on line 454.
|
Flake errors fixed |
|
Since Travis didn't run on the latest commit, for some reason, I pushed the branch to my repo: https://travis-ci.org/effigies/nibabel/builds/110833187 Tests passing. |
| @@ -661,3 +662,20 @@ def __getitem__(self): | |||
| raise TypeError("Cannot slice image objects; consider slicing image " | |||
| "array data with `img.dataobj[slice]` or " | |||
| "`img.get_data()[slice]`") | |||
|
|
|||
| def plot(self): | |||
There was a problem hiding this comment.
plot seems a little generic. How about orthoview?
… 4D data sets Add tests and update the OrthoSlicer3D docstring to describe 4D support.
larsoner
force-pushed
the
pauls-viewer
branch
from
f2e5ea2 to
4d47d5a
Compare
larsoner
force-pushed
the
pauls-viewer
branch
from
4d47d5a to
2a8a73c
Compare
|
Comments addressed @matthew-brett. I would probably have time to be secondary mentor on a project, providing guidance mostly on the plotting end of things with |
| class OrthoSlicer3D(object): | ||
| """Orthogonal-plane slicer. | ||
|
|
||
| OrthoSlicer3d expects 3-dimensional data, and by default it creates a |
There was a problem hiding this comment.
Maybe say 3- or 4-dimensional data here.
|
Actually - forget the comment - in it goes, I'll do a follow up PR in a second. Thanks all for being patient, and thanks Eric for the nice work on this one. |
MRG: Slice viewer Orthogonal slice viewer for 3D and 4D images. Based on Paul Ivanov's prototype. Viewers can be yoked so that crosshairs correspond to matching voxel coordinates according to the image affines.
MRG: Slice viewer Orthogonal slice viewer for 3D and 4D images. Based on Paul Ivanov's prototype. Viewers can be yoked so that crosshairs correspond to matching voxel coordinates according to the image affines.
Let's see if Travis is happy. The rebase wasn't too bad.