Change in pixels using reslice function

Hi all,

I have a question regarding the reslice [/] function in ImageJ and the translation towards Matlab. First let me introduce my problem.

I use polylines (straight segmented lines) to make a ROI. When I make a reslice of this ROI within a stacked 336x60 pixel image (recording), I get a kymograph (time space plot). The height of this plot is determined by the length of my ROI. Let’s say that the height of the kymograph is 61 pixels.

I now want to import this particular ROI into Matlab and I can do this in two ways (presumably more), I can make a black 336x60 image and draw the ROI on top and save this image as a (1) .tif or (2) .txt file. If I now want to calculate the length of the ROI in Matlab (or the height of the kymograph), it gives my a length of 59 pixels. The calculation of the length in Matlab is always smaller in Matlab compared to ImageJ. And here lays my problem. Even when I count the amount of pixels of the ROI in the drawing I made, I see that Matlab is right every time.

My question is why ImageJ gives me more pixels in the reslice I generate? Or even better, is there any way to circumvent this problem? (Note: the difference in length is bigger if the ROI is bigger, but this relationship is not proportional)

I’d really like to have you share some thoughts on this matter. Thanks in advance.

Cheers, Mike

Hi Mike,

Some example images or screenshots would certainly help others to understand your problem. I’m not sure if I correctly understood how you were drawing the segmented lines, but I definitely observed some inconsistencies when using segmented lines and the Reslice command. Below I pasted screenshots of a simple small image stack (containing a small white square and a black last slice) with some ROIs, and their resliced result:

Two segments of length 6 pixels => 12 pixels

Four segments of length sqrt(5) = 4 * 2.236 = 8.944 => 8 pixels

The pixels used for reslicing apparently are offset by half a pixel to the bottom left (due to the concept of placing line points between pixel coordinates).

I’d say that’s just a question of implementation, but maybe @Wayne can comment more on this.