Are the NPP LabelMarkers and CompressMarkerLabels routines buggy?

There are two approaches to labeling images in the NPP libraries, the original and the newer UF version, both of which appear to be buggy on my system.

I have been experimenting by modifying the input to this great example by Robert Crovella

All tests were performed using CUDA 11.3 on Windows 10 compiled with VS and executed on a mobile RTX 2080.

My observation regarding the original approach is that if all the elements of the input array to nppiLabelMarkers_16u_C1IR are zero except for (x,y)

  1. (0,0), the labeled output is garbage,
  2. (1,0), the labeled output is empty (this also seems to be true if any “connected” region only contains one element).

The UF variant also exhibits strange behavior if all the elements of the input array are zero except for (0,0). In this case everything is labeled 1 except (0,0) which is labeled 0.

I have tried to use nppiCompressedMarkerLabelsUFInfo_32u_C1R_Ctx however I can’t seem to get the correct output. The structure of NppiCompressedMarkerLabelsInfo::oMarkerLabelBoundingBox should be an NppiRect with x,y,width,height as fields, however in the output I am getting the width and height look more like maxX and maxY. Additionally even making this adjustment not all of bbox info is correct when I use the function with the example input.

On a side note, is it possible to keep both approaches instead of depreciating the older non UF version. I am asking because the execution time of the UF variant appears independent of the structure of the source and as a result it is significantly slower than the original when the input is mostly zero or even completely zero.

They might be buggy. Bugs are always possible. I personally wouldn’t be able to spend any time on it without a full test case.

If you have full test cases you can always file a bug if you wish. You can also file a bug to make your request known to keep the deprecated version(s).