Back to the main page.
Bug 2640 - ft_plot_slice does not draw the intersection with a surface mesh correctly
| Status | CLOSED FIXED |
| Reported | 2014-07-08 10:05:00 +0200 |
| Modified | 2014-07-15 17:25:07 +0200 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2014-07-08 10:05:53 +0200
Created attachment 651 screen shot showing incorrect intersection The following code reproduces the problem: dim = [20, 25, 30]; dat = 0.1*randn(dim); selx = 5:(dim(1)-5); sely = 5:(dim(2)-5); selz = 5:(dim(3)-5); dat(selx, sely, selz) = dat(selx, sely, selz) + 1; transform = eye(4); [mesh.tri, mesh.pnt] = isosurface(dat); figure ft_plot_slice(dat, 'transform', transform, 'intersectmesh', mesh); grid on xlabel('x') ylabel('y') zlabel('z')
Robert Oostenveld - 2014-07-08 12:06:36 +0200
It turned out to be due to isosurface returning the coordinates inconsistent with my expectations. The following works fine dim = [20, 30, 40]; dat = 0.1*randn(dim); selx = 5:(dim(1)-5); sely = 5:(dim(2)-5); selz = 5:(dim(3)-5); dat(selx, sely, selz) = dat(selx, sely, selz) + 1; transform = eye(4); [f, v] = isosurface(dat>0.5); mesh.tri = f; mesh.pnt = v(:,[2 1 3]); figure ft_plot_slice(dat, 'transform', transform, 'intersectmesh', mesh); grid on xlabel('x') ylabel('y') zlabel('z')
Robert Oostenveld - 2014-07-08 12:13:48 +0200
while trying to debug, I made some small changes to the handling of the corner points. mac011> svn commit Sending ft_plot_slice.m Sending private/cornerpoints.m Transmitting file data .. Committed revision 9706.
Robert Oostenveld - 2014-07-08 12:18:42 +0200
looking closely, there is one remaining issue which is most obvious with figure ft_plot_ortho(dat, 'transform', transform, 'style', 'intersect', 'intersectmesh', mesh); grid on xlabel('x') ylabel('y') zlabel('z') The intersection with the mesh is not exactly at the slice, but hovers above it. The consequence is that it is visible from one side, but not the other.
Robert Oostenveld - 2014-07-08 12:19:58 +0200
with grid on axis on it is clear that the mesh intersection is at the correct place, but the slice itself is not.
Robert Oostenveld - 2014-07-08 12:50:52 +0200
also shift Zi with 0.5 voxel in dointerp, otherwise it is inconsistent between dointerp=true and dointerp=false mac011> svn commit Sending ft_plot_slice.m Transmitting file data . Committed revision 9708. mac011> svn commit Sending ft_plot_slice.m Transmitting file data . Committed revision 9709.
Robert Oostenveld - 2014-07-08 13:45:37 +0200
the following is also giving me issues: dim = [3 3 3]; dat = zeros(3,3,3); dat(2,2,2) = 1; transform = eye(4); mesh.pnt = [ 0 0 0 0 0 1 0 1 0 1 0 0 0 1 1 1 0 1 1 1 0 1 1 1 ] - 0.5; mesh.tri = convhulln(mesh.pnt); figure; ft_plot_slice(dat, 'transform', transform, 'intersectmesh', mesh); figure; ft_plot_slice(dat, 'transform', transform, 'intersectmesh', mesh, 'location', [1.5 1.5 1.5]); figure; ft_plot_slice(dat, 'transform', transform, 'intersectmesh', mesh, 'location', [2 2 2]);
Robert Oostenveld - 2014-07-09 11:00:46 +0200
mac011> svn commit ft_plot_slice.m Sending ft_plot_slice.m Transmitting file data . Committed revision 9710. mac011> svn commit test_bug2640.m Adding test_bug2640.m Transmitting file data . Committed revision 9711. mac011> svn commit test_bug2640.m Sending test_bug2640.m Transmitting file data . Committed revision 9712. I revamped the internal organisation of the code, especially with regards to the grid handing and the explicit specification of coordinate systems (head, voxel and projection plane). The dointerp is not used at the moment, I will discuss with Jan-Mathijs whether that needs to be added again. I also added a test script, which now correctly displays the slices with the intersection and with the mesh
Jan-Mathijs Schoffelen - 2014-07-09 11:06:01 +0200
What's the specific reason for the functionality to be removed. I'd rather keep it in, were it alone for the reason that the QC figures in the HCP anatomy pipeline involve several visualizations along the world-coordinate system's axes, requiring replacing on the fly.
Robert Oostenveld - 2014-07-09 11:07:58 +0200
(In reply to Jan-Mathijs Schoffelen from comment #8) replacing on the fly should still work. I'll drop by for a coffee and go over the changes with you...