This happens with the current image-2.6.1 package and Octave 4.2.0.

The current Octave implementation of poly2mask.m rounds its polygon input values to the nearest integer (and correctly says so in its documentation).

In contrast, the Matlab implementation of poly2mask.m also uses fractional input values, and does some 5-by-5 subsampling of pixels. See the Matlab documentation: https://de.mathworks.com/help/images/ref/poly2mask.html#f6-465457

As a result the output values between the Octave and the Matlab version of poly2mask are different.

Here is some typical code that shows the difference, and can be used for implementing an improved version of Octave's poly2mask:

clear;

poly_a = [...
    2   2.5
    1.5 3
    2   3.5
    4   3.5
    4.5 3
    4   2.5
    2   2.5];

mask_a = poly2mask( poly_a(:,1), poly_a(:, 2), 5, 5)

mask_a_matlab = logical([ ...
     0     0     0     0     0
     0     0     0     0     0
     0     1     1     1     0
     0     0     0     0     0
     0     0     0     0     0])

poly_b = [...
    2 2
    9 4
    9 5
    2 5
    2 2];

mask_b = poly2mask( poly_b(:,1), poly_b(:, 2), 6, 11)

mask_b_matlab = logical([ ...
     0     0     0     0     0     0     0     0     0     0     0
     0     0     0     0     0     0     0     0     0     0     0
     0     0     1     1     1     0     0     0     0     0     0
     0     0     1     1     1     1     1     1     0     0     0
     0     0     1     1     1     1     1     1     1     0     0
     0     0     0     0     0     0     0     0     0     0     0])

The current output of Octave is:

mask_a =

  0  0  0  0  0
  0  0  0  0  0
  0  0  0  0  0
  0  0  1  1  0
  0  0  0  0  0

mask_a_matlab =

  0  0  0  0  0
  0  0  0  0  0
  0  1  1  1  0
  0  0  0  0  0
  0  0  0  0  0

mask_b =

  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0
  0  0  1  1  1  1  0  0  0  0  0
  0  0  1  1  1  1  1  1  1  0  0
  0  0  1  1  1  1  1  1  1  0  0
  0  0  0  0  0  0  0  0  0  0  0

mask_b_matlab =

  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0
  0  0  1  1  1  0  0  0  0  0  0
  0  0  1  1  1  1  1  1  0  0  0
  0  0  1  1  1  1  1  1  1  0  0
  0  0  0  0  0  0  0  0  0  0  0

(I hit this bug while implementing a new feature in regionprops.m. I will probably work around this bug in regionprops, to not introduce more dependencies of patches. This means that a future fix to this bug could have a look what's been done in regionprops.m for the 'ConvexImage' calculation.)