[BUG] load_annotations from CVAT "text" attribute treated as "int" when using only digits

[aguevaracaprio]

Describe the problem

When using CVAT as backend to download "text" attributes, FiftyOne automatically treats text that is digit-only as number/int type. This is causing issues when annotating text that begins with 0. For example, an objected annotated as "0001" -> 1. CVAT does export the "text" attribute correctly with all characters but FiftyOne seems to automatically treat it as a number

Not sure if this is a bug or expected behavior, but I would want to know how we can prevent this from happening as this affects our labeling process

Code to reproduce issue

1. Create a CVAT schema with an attribute of type text
2. Create an annotation job an input text with all-digit characters but adding leading zeros (e.x. 001)
3. Use load_annotations function to download the new labels into the dataset
4. Verify that the label attribute is an int and leading zeros have been removed

System information

• OS Platform and Distribution Linux Ubuntu 24.04.3 LTS)
• Python version 3.10
• FiftyOne version (fiftyone --version): v1.10.0
• FiftyOne installed from (pip or source): pip

The FiftyOne Community encourages bug fix contributions. Would you or another
member of your organization be willing to contribute a fix for this bug to the
FiftyOne codebase?

• Yes. I can contribute a fix for this bug independently
• Yes. I would be willing to contribute a fix for this bug with guidance
  from the FiftyOne community
• No. I cannot contribute a bug fix at this time

[aguevaracaprio]

The problem causing this issue seems to be in

_parse_value under fiftyone.utils.cvat

[brimoor]

The root problem here is that CVAT doesn't support (or at least didn't when we built the integration) the concept of what "value type" an attribute has, only what "component type" should be used in their UI to collect the values.

Furthermore, when we built the CVAT integration, I believe the only component types they supported were the ones we've documented support for:

• text: a free-form text box. In this case, default is optional and values is unused
• select: a selection dropdown. In this case, values is required and default is optional
• radio: a radio button list UI. In this case, values is required and default is optional
• checkbox: a boolean checkbox UI. In this case, default is optional and values is unused
• occluded: CVAT’s builtin occlusion toggle icon. This widget type can only be specified for at most one attribute, which must be a boolean
• group_id: CVAT’s grouping capabilities. This attribute type can only be specified for at most one attribute, which must be an integer

That meant the only tool to collect strings, ints, and floats was via the text type, which was ambiguous. Hence why we adopted a greedy strategy of converting to opinionated types when loading into FO, because in practice you're much more likely (but not guaranteed, per this issue) to want to work with the data as numeric types, not strings.

I see two options here, which I've described below.

Option 1

Do what has been proposed in #7252.

Provide an opt-out way to disable automatic conversion of CVAT text attributes into opinionated FO attribute types:

import fiftyone.utils.cvat as fouc

# All CVAT `text` attributes are stored as FO string attributes upon import
dataset.annotate(..., coerce_text_attrs=False)
fouc.import_annotations(..., coerce_text_attrs=False)

Importantly: for backwards compatibility, the default should be coerce_text_attrs=True.

This would entail coerce_text_attrs being added to CVATBackendConfig.

Option 2

Upon a quick search, I believe that CVAT now supports a number type. We could update our integration to use that for numeric attributes. I believe this would involve allowing users to specify min|max|step values as well which would inform a slider UI or similar in CVAT.

That still wouldn't necessarily disambiguate between integer and floating point fields, so we could introduce int and float options for the `type field:

label_schema = {
    "ground_truth": {
        "classes": ["vehicle"],
        "attributes": {
            "make": {"type": "text"},
            "model": {"type": "text"},
            "year": {"type": "int"},  # uses `number` tool in CVAT, parsed via `int()` when loaded back into FO
            "mpg": {"type": "float"},  # uses `number` tool in CVAT, parsed via `float()` when loaded back into FO
        }
    },
}

dataset.annotate(..., label_schema=label_schema)

That would mean that type contains a mix of "component types" and "value types", which is unfortunate...

[brimoor]

I think we should just go with Option 1 for simplicity.

For more fine-grained control over annotation schemas, I strongly recommend that folks look into native annotation in FiftyOne 😎