Release v2.29.0 #9080
Merged
Release v2.29.0 #9080
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![cvat-bot[bot]](https://avatars.githubusercontent.com/in/406724?s=60&v=4){kind=small}
Update develop after v2.28.0
Currently, the default is `unknown`, but allowing `unknown` as a function label type value creates some complications. * The sets of allowed label types of a task and of a function are not the same, so we have to use different enums to represent them. * `any` and `unknown` have similar meanings, and it's not clear what the difference between them is unless you search the code (AFAIK it's not documented anywhere). The sole benefit of having a separate `unknown` label type seems to be that function labels of type `any` are only allowed to be mapped to task labels of type `any`, while function labels of type `unknown` can be mapped to task labels of any type. But it doesn't seem like a useful distinction. Functions with both `unknown` and `any` label types can produce any shape types, so if we allow one of them, it makes sense to also allow the other. In addition, functions that can produce _multiple_ shape types for a single label are probably going to be rare, so I think it's reasonable to assume that a function with an `any`-typed label will still produce a single shape type and therefore can be mapped to a label with a specific type (although the user is responsible for ensuring that the types actually match). To sum up, I don't think the additional complexity introduced by the `unknown` type is worth it. So let's remove it and use `any` instead. This PR keeps some `unknown`-related logic in the UI, since there's some code in the Enterprise backend that also uses `unknown` as a label type. If this patch is accepted, I'll replace those uses with `any` too, then go back and remove the remaining logic here.
If a task or a job contains deleted frames that contain track keyframes, these keyframes should be excluded from the interpolation. However, in jobs having specific frames included (e.g. GT jobs), deleted frames should not be confused with included frames during track interpolation. Deleted frames should affect existing shapes in tracks, while included frames should only filter the resulting annotations after interpolation. This PR implements this approach.
…9035) This will enable more accurate label type information in the function API, which is used in a few places (for example, in the "From model" feature available when configuring labels for a task).
cvat-bot
bot
requested review from
azhavoro,
zhiltsov-max,
bsekachev and
SpecLad
as code owners
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #9080 +/- ##
==========================================
+ Coverage 73.75% 73.91% +0.15%
==========================================
Files 428 428
Lines 44514 44530 +16
Branches 3881 3881
==========================================
+ Hits 32830 32913 +83
+ Misses 11684 11617 -67
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added
Tasks created from cloud storage can be backed up now (backup task created from cloud #8972)
[CLI]
function create-nativenow sends the function's declared label types to the server (CLI: Letfunction create-nativesubmit label types to the server #9035)Changed
anycan now be mapped to labels of all types exceptskeleton(Useanyas the default function label type #9050)Fixed