[edit: fix spelling errors (twice), no changes to code.]
[Edit: Replace color images with new images that don't have an error in the right hand panel.]
@Catalytic is right that the pixel size in the new, oblique slice is 1, when measured in the units of the pixels in the original image (i.e. assuming each of the original pizels has size 1x1x1). obliqueslice(V,point,normal)
It helps me to think of an oblique slice as a setting up a new reference frame that is oriented obliquely relative to the original frame. The original frame has axes Xo,Yo,Zo. The new frame's axes are Xn,Yn,Zn. Zn points along vector "normal". The new image is in the Xn,Yn plane. Let Zn=0 at point "point". Then all the points in the oblique slice have Zn=0. Now create a grid of points with spacing 1x1 in the Xn,Zn plane. Those are the pixel centers in the new image. We can transform those back to their location in the original volume reference frame. The pixel centers in the oblique slice will not exactly coincide with voxel centers in the original slice, so at each pixel center, obliqueslice() takes a weighted average of the image intensities at the nearest voxel centers of the original image.
Since the pixels in the oblique slice have size 1x1, and the plane is tilted relative to the original volume, the oblique plane is likely to have more pixels that the original volume, at least if it passes through the center of the volume. And this is in fact what you will observe.
One thing that is interesting about the change of coordinates way of thinking about obliqueslice() is that the direction of Xn and Yn is not specified by vector "normal". So obliqueslice() decides how to orient Xn and Yn. Sometimes I like obliqueslice()'s choice for Xn and Yn, and sometimes I do not.
I have attached a script, image3dslice.m, to illustrate some aspects of how obliqueslice() works.
image3dslice.m creates a mostly black volume with array dimensions 81x71x91, i.e 81 pixels along axis Yo, 71 along Xo, and 91 along Zo. There is a white plane at every 10th pixel, i.e. at 1, 11, 21,..., in all 3 directions.
The first part of image3dslice.m takes slices parallel to the original axes, and plots them. When normal=[0,0,1], i.e. normal points along the Zo axis, then the slice is in the X-Y plane. Point "point" is chosen to be in a black area, so the resulting slice is mostly black, with size 81 rows x 71 columns, and a grid of white lines up/down and across, at every 10th pixel. See left panel in figure below. I call imshow() with the "xy" option, which puts the X,Y origin at the bottom left. When normal=[0,1,0], i.e. normal points along Yo, then the slice is parallel to the X-Z plane, and the image slice has size 91 rows by 71 columns. It is mostly black, with white lines at every 10th pixel. See center panel in figure below. When normal =[1,0,0], the normal points along Xo, and the image slice is in the Y-Z plane, and it has the expected dimensions - see right panel in image below.
The second part of image3dslice.m take slices at oblique angles. For simplicity, the normal vector in the three examples below is rotated about just one of the orignal axes. This means the normal vector has one of its coordinates=0 in each of the three examples shown. The normal vector is rotated by 18.4 degrees. I chose this angle because the tangent of 18.4 degrees is 1/3, so the tilted plane goes 1 original voxel up for every 3 voxels over, and we will see this pattern in the results.
Note that the tilted planes have more pixels, in some directions, than the original volume dimensions. The left panel below shows the slice when normal=[ 0,.316,.949]. This normal vector is close to the Zo-axis, but it is tilted 18.4 degress toward the Yo-axis. The plane normal to "normal" has x-values identical to the original x values (because the x-component of normal=0), and the y-values are close to, but not identical to, the original y values. That is why I labeled the axes "X" and "Y*". There are 84 rows in the slice, compared to 81 rows in the orthogonal slice on the left in the previous figure. The extra pixels in the oblique slice reflect the fact that the tilted plane inside the volume is longer than the volume is tall.
The right hand panel in the image blow shows a case where obliqueslice() selected Xn and Yn axes in what I think is an unhelpful way. Since normal=[.316,.949,0], one could have chosen to let Yn (columns of the oblique slice) point in direction [0,0,1] (in the originial reference frame), and let Xn (rows of the slice) point in direction [.949,-.316,0]. Then the rows of the slice image would correspond to Zo in the volume, and the right hand slice below would look nice and rectangular, instead of being tilited.
There is a lot more one could say about the image slices above, including to evidence for 3 to 1 ratios, etc.
Matlb's obliqueslice() does not work with color volume images. Matlab's sliceViewer does display color volume images, but it does not allow oblique slicing. If you make a volume image like the one I made above, but with red, green, and blue planes in the different directions, instead of all white planes, then the oblique slices would be more revealing. With a small effort, you could write a function to apply obliqueslice() to the red, green, and blue planes of an image, then combine the slices to make a color oblique slice. So I did.
