Added smart attribute keeping when changing label

[timurlenk07]

Motivation and context

Implements #2755 and #3294. Basically, when changing label class, attributes are retained IF and only there is an attribute with the same name and type, and the old value is still valid in the new configuration.

How has this been tested?

Tested manually on rectangle labels with various attributes.

Checklist

• I submit my changes into the develop branch
• I have added description of my changes into CHANGELOG file
• I have updated the documentation accordingly
• I have added tests to cover my changes
• I have linked related issues (read github docs)
• I have increased versions of npm packages if it is necessary (cvat-canvas,
  cvat-core, cvat-data and cvat-ui)

License

• I submit my code changes under the same MIT License that covers the project.
  Feel free to contact the maintainers if that's a concern.
• I have updated the license header for each file (see an example below)

# Copyright (C) 2021 Intel Corporation
#
# SPDX-License-Identifier: MIT

[timurlenk07]

As I work with images, I did not know whether attribute mutability should be considered in the attribute keeping decision. Someone better informed could tell me, what would be the correct way to handle that?

[bsekachev]

Hi, sorry for delay in my response.
Generally works fine with shapes and tags, one minor comment about attribute types compatibility. Should we try to keep compatble attributes?

For tracks need to write similar code in Track::_saveLabel at the same file. Do you have an ability to do it? If not, it is okay, we can merge the PR as is.

Also, please add a line to CONTRIBUTING.md and do npm version patch in cvat-core to update its version.

[bsekachev]

input types "select" and "radio" are fully compatible
we can also check compatibility additionally between "text" and "radio' or "select"

[timurlenk07]

I could make the code to work similarly with tracks, though I won't have the possibility to test it.
Will do the line in CONTRIBUTING.md and the version patch, but I did not understand this question of yours:

Generally works fine with shapes and tags, one minor comment about attribute types compatibility. Should we try to keep compatble attributes?

Could you explain that a bit? Or was it about what you've commented on the code?

[bsekachev]

Generally works fine with shapes and tags, one minor comment about attribute types compatibility. Should we try to keep compatble attributes?

Sure, I will try to rephrase.

As you probably know CVAT supports different types of attributes: CHECKBOX, SELECT, RADIO, TEXT and NUMBER.
Internally SELECT and RADIO are the same meaning (one of a list). So, they are compatible from this point of view and if attributes have the same name (and compatible values), we could try to keep it also regardless of different types.

Speaking about TEXT attributes, we definitely can convert SELECT and RADIO to TEXT with no any issues. And we can do a reverse thing if TEXT attribute value is a possible value for RADIO or SELECT attributes.

[timurlenk07]

Now I get it. I will try to do these this week.
Should I rebase onto the latest master commit before doing npm version patch?

[timurlenk07]

Now I only check if the attribute names are the same, and if the old value is still valid in the new attribute. This works even for checkboxes, though I am not sure if that is a desired behaviour.

[bsekachev]

@dvkruchinin

Probably we already have a test to change a label, can we update it to cover this case?
Both labels must have an attribute with compatible values.

[dvkruchinin]

@dvkruchinin

Probably we already have a test to change a label, can we update it to cover this case?
Both labels must have an attribute with compatible values.

Sure. I'll check and prepare a corresponding task.