Patch: Problem with rasterization of line and point ROIs (issue #30)

[imagingbook]

This is a proposed patch for issue #30.

[rasband]

These fixes are in the latest ImageJ daily build (1.51m28).

[rasband]

The modified ImageProcess.getLine() method is not in the released version of ImageJ 1.51m. It does not behave the same way as the original version, potentially causing compatibility problems.

[imagingbook]

I understand, compatibility is important. Though I guess it is the very idea of a bug fix to change behavior...

[rasband]

The modified version of getLine() did not always behave as expected. For example, it returned a 3 element array for lines 1.1 pixels long. Here is some JavaScript code that demonstrates this behavior:

ip = new ByteProcessor(100,100);
ip.setInterpolate(true);
values = ip.getLine(100.0,100.0,100.0,101.1);
print("values.length: " + values.length);

[imagingbook]

I will look into this problem asap. A possible deeper problem is that there are two different interpretations of floating-point coordinates in ImageJ:

1. ROI coordinates: The image pixel (u, v) is interpreted to extend over the rectangle x in [u, u+1) and y in [v, v+1). Thus, the exact center of the image pixel at integer grid position (0,0) has the ROI position (0.5, 0.5). By rounding, all ROI coordinates in the range [u-0.5, u+0.5) are mapped to the grid position u.

2. Sample coordinates: In contrast, when calling ip.getLine(x1, y1, x2, y2), the floating point coordinates mean positions in the sampling plane. In this case, the point (0.0, 0.0) is exactly ON the sample position (0,0).

Thus there is a systematic offset of (0.5, 0.5) between these two coordinate systems, and I am not sure if currently this is properly addressed. Assuming that related operations should share a common semantics, the question is where to correct for this offset. I suppose it should happen consistently in the ROI context and coordinates should refer to the sample raster everywhere else. Any better options?

--Wilhelm