Why does skeletonization sometimes reduce horizontal rectangles to single pixels?

Skeletonization (bwskel) of a horizontal rectangle may sometimes result in a single pixel. Can anybody explain why (the logics) and what to do to resolve this issue (illustrated below)?

-------------

Create black binary image and add four white rectangles

bw = false(30,55);
bw(5:9,5:15) = true;        % Placed NW
bw(5:9,30:51) = true;       % Placed NE
bw(20:25,5:15) = true;      % Placed SW
bw(20:25,30:51) = true;     % Placed SE

Show image and corresponding skeletonized image

imshow(bw)

imshow(bwskel(bw))

For two of the rectangles the skeletons reduce to single pixels. Why?

The same thing does not happen for 45 degr. rotated rectangles.

Rotated version of image

bwrot = imrotate(bw,45);

Show rotated images and its skeletonized counterpart

imshow(bwrot)

imshow(bwskel(bwrot))

For 90 degr. rotated rectangles the same two rectangles reduces to single pixels when skeletonized. However, the pixels are now placed differently.

bwrot = imrotate(bw,90);

Show rotated images and its skeletonized counterpart

imshow(bwrot)

imshow(bwskel(bwrot))

Answer 1

[Matt J]

It is because the lower rectangles have an even number of rows, so their "center line" in continuous space does not coincide with the centers of a line of pixels.

To resolve, make the number of rows odd, e.g.,

bw = false(30,55);
bw(5:9,5:15) = true;        % Placed NW
bw(5:9,30:51) = true;       % Placed NE
bw(21:25,5:15) = true;      % Placed SW
bw(21:25,30:51) = true;     % Placed SE

[Matt J]

Note that bwmorph has different behavior for some reason and will leave 4 lines, but I don't know that it is preferable. The thinned lines on the bottom are not (and cannot be) centered in the original rectangles.

bw = false(30,55);
bw(5:9,5:15) = true;        % Placed NW
bw(5:9,30:51) = true;       % Placed NE
bw(20:25,5:15) = true;      % Placed SW
bw(20:25,30:51) = true;     % Placed SE

imshow(bwmorph(bw,'thin',inf))

[Henning Søgaard]

Thanks Matt - bwmorph(bw,'thin',inf) is actually better for my application.

One comment: you say that my problem with bwskel will arise for rectangles with an even number of rows. However, this is not always the case, and I cannot understand why. In my example below i am testing rectangle heights of 2:2:30, and the problem only arises for the following heights: 4, 6, 10, 12, 16, 18, 22, 24. I can see a system (a cycle of 3, height < width), but I don't understand it fully.

Code:

maxrecth = 30; offsrect = 4;
imh = maxrecth + 2*(offsrect-1); imw = 31;
h1px = [];
for recth = 2:2:maxrecth
  bw = false(imh,imw);
  bw(offsrect:offsrect+recth-1,offsrect:imw-offsrect+1) = true;
  ttl = sprintf('Original\nh = %s', num2str(recth));
  figure
  subplot(1,2,1);
  imshow(bw)
  title(ttl)
  skelbw = bwskel(bw);
  ttl = sprintf('Skeleton\nh = %s', num2str(recth));
  subplot(1,2,2);
  imshow(skelbw)
  if sum(skelbw(:)) == 1
    ttl = sprintf(['%s\n> 1 px left <'],ttl);
    h1px = [h1px recth];
  end
  title(ttl)
end
h1px

Examples of output:

[Matt J]

It's a mystery to me. Fortunately, though, if we loop over the odd numbers,

for recth = 1:2:maxrecth

a line skeleton is always observed.

Answer 2

[Catalytic]

Remember what bwskel is doing. It is peeling the outer pixels of the rectangles like an onion over and over again until it reaches a shape that is 1 pixel wide. Because the bottom 2 rectangles have an even number of pixel rows, this process can be repeated until the shape essentially disappears.