I'll keep this brief. Based on the semantics of json2labelImg.py, the json2instanceImg.py has a typo which will lead to labeling "caravan" and "trailer" as instance classes instead of void, when using "trainIds" encoding, for some images.
In https://github.com/mcordts/cityscapesScripts/blob/master/cityscapesscripts/preparation/json2instanceImg.py#L141-L143:
if labelTuple.hasInstances and not isGroup and id != 255:
id = id * 1000 + nbInstances[label]
nbInstances[label] += 1
should be as follows, were we use labelTuple.trainId instead of id when comparing to 255.
if labelTuple.hasInstances and not isGroup and labelTuple.trainId != 255:
id = id * 1000 + nbInstances[label]
nbInstances[label] += 1
If someone doesn't want to fix the code, one "solution" would be to just not use train IDs, but use original label IDs which don't have this issue, and then use the mapping in cityscapesscripts when loading in the data. Also I'm not entirely sure this matters if one is ignoring these classes when loading in the data. But depending on how the data is used, it could lead to issues.
I'll keep this brief. Based on the semantics of
json2labelImg.py, thejson2instanceImg.pyhas a typo which will lead to labeling "caravan" and "trailer" as instance classes instead of void, when using"trainIds"encoding, for some images.In https://github.com/mcordts/cityscapesScripts/blob/master/cityscapesscripts/preparation/json2instanceImg.py#L141-L143:
should be as follows, were we use
labelTuple.trainIdinstead ofidwhen comparing to 255.If someone doesn't want to fix the code, one "solution" would be to just not use train IDs, but use original label IDs which don't have this issue, and then use the mapping in cityscapesscripts when loading in the data. Also I'm not entirely sure this matters if one is ignoring these classes when loading in the data. But depending on how the data is used, it could lead to issues.