Fix for NamesAndTypes incorrectly relabeling 3D objects from an image

[callum-jpg]

Tentative fix for CellProfiler/CellProfiler#4505

When loading objects from a 3d image, NamesAndTypes relied on a method (specifically, get_image_volume in core _objects_image.py) that labelled planes individually using convert_image_to_objects and stacked the result. As some cells can be present in one plane but not others, this led to differences in labelling for the same cell between planes. By removing the label recalculations, the original segmentation is preserved.

@DavidStirling , is there some particular scenario this original fix was trying to solve? We note that planes are converted from int64 to int32 here, which we have preserved, so wondered if theres some particular case we are overlooking here. Could it also be that convert_image_to_objects was called to help deal with missing objects, similar to CellProfiler/CellProfiler#4485?

[DavidStirling]

@callum-jpg Sorry I missed this! I don't think it's originally my code but came over from the main repo during the core split.

I expect that the intention was to handle missing label values. I'm sure that there will now be far more efficient ways to achieve the same thing as the utility function convert_image_to_objects does, for now perhaps adapting that to natively handle 3D would be a reasonable solution.