Question about the instance ID in SemKittiDVPS dataset

[QingCheng24]

Hello, I have a question about the instance ID in SemKittiDVPS dataset.

The instance GT image is read with
instance = cv2.imread(instance_path, cv2.IMREAD_ANYDEPTH)

The following are the unique instance IDs from the val set. It looks like that the instances are labelled incrementally but the total number of ids is 354 instead of 396 which is indicated by the final instance id. So I'm a little bit confused about the meaning of the ids. Could you please give some description for this.

$0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26,27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, $
$41, 42, 43, 44, 45, 46, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, $
$81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, $
$117, 118, 119, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 133, 134, 135, 137, 138, 139, 140, 141, 142, 143, 145, 146, 147, 148, 149, 150$
$151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 182, 183,$
$184, 189, 190, 191, 192, 193, 194, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, $
$216, 217, 218, 219, 220, 229, 231, 232, 233, 234, 235, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, $
$254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 269, 270, 271, 272, 273, 274, 275, 276, 277, 279, 280, 283, 284, 286, 287, $
$288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 300, 301, 302, 303, 304, 305, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, $
$318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, $
$346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 369, 370, 371, 372, 373, 374, $
$375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 386, 387, 390, 391, 392, 393, 394, 395$

[jbehley]

I was not involved directly involved in the SemKitti DVPS processing, as these were handled by a different team. Therefore, I can only provide some insights into the labeling process of the instances that might explain the non-consecutive instance ids:

As described in the ICRA 2021 paper on the panoptic segmentation benchmark (see PDF, we used an semi-automatic process for augmenting the semantic segmentation labels with instances. We used a heuristic clustering approach, grid-based clustering and a euclidean clustering, for getting initial instances, which we later then manually refined by either joining or splitting instances. I think I didn't remapped the instance ids to consecutive numbers after this and just kept the ids.

Thus, if you rely on consecutive instance ids, you have to remap the ids per class. Note that instance ids are assigned per class, thus, if you want to have unique ids, you anyway have to remap the ids.