Add Rename Classes UQL Operation

[NickHerrig]

Description

This PR adds UQL operation to handle renaming of classes given a class_map.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How has this change been tested, please provide a testcase or example of how you tested the change?

• Integration tests passing
• Local inferences server in Workflow UI

[NickHerrig]

@PawelPeczek-Roboflow let me know if you have any feedback any here from our convo today.

[PawelPeczek-Roboflow]

There is one issue with potential collapse of class id:
original detections have 1-1 relationship between class name and class id, after mapping this is not guaranteed.
Additional difficulty is also keeping original class.

Maintaining classes ids may be important - for instance to have visualisation that works consistently (look how this is implemented in supervision)

Proposed solution:

• enforce full mapping - if not given raise operation error
• when classes collapse - keep lower class id

if for some reason we wish to let non-strict class mappings, I suggest adding operation parameter (strict: bool with default True), such that people take risk by willingly declaring so.

[PawelPeczek-Roboflow]

please report image credits

[NickHerrig]

Complete

[PawelPeczek-Roboflow]

great tests coverage

[NickHerrig]

@PawelPeczek-Roboflow Hey Pawel, I couldn't figure out or find a good example of passing Input Parameters into UQL operations for tests. Instead I created a hacky work around with parameterized tests to replace the Workflow Specification to test scenarios. Feel free to change this if you'd like; as I would also like to learn how to pass input parameters into UQL operations for future work.

[PawelPeczek-Roboflow]

@NickHerrig planning release tmrw - would u be able to apply changes? if not I can help, but let's agree on what we do with doubts I raised

[NickHerrig]

@PawelPeczek-Roboflow yes I have time now to complete these changes. I agree with your proposed solution to avoid same class names having different class-id(collapse) causing variability in annotation color, etc.

[PawelPeczek-Roboflow]

ok, great

[NickHerrig]

@PawelPeczek-Roboflow I implemented most of your propsal, with one slight addition to handle the case of assigning new class_ids when a class name does not exist in the original detections.

• If strict mode is enabled (which is the default), the function will raise an OperationError if any class name in the original detections is not found in the class_map. This ensures that every class name in the detections must have a corresponding mapping in the class_map.

• If strict mode is disabled (strict=False), the function will not raise an error for unmapped class names. Instead, it will use the original class name if it is not found in the class_map.

• If a new class name already exists in the new_class_names list, the function reuses the corresponding class ID.

• If a new class name does not exist in the original detections, the function assigns a new class ID by incrementing the maximum class ID found in the original detections. This ensures that new class IDs do not conflict with existing ones.

Feel free to make changes if you see a problem with this approach.

[PawelPeczek-Roboflow]

Added additional params to avoid collisions, tested and refactored the code to avoid O(n^2) complexity

[PawelPeczek-Roboflow]

@hansent @EmilyGavrilenko - this would need to be implemented on UI end: #656

[NickHerrig]

Thanks for your help @PawelPeczek-Roboflow getting this across the line!