Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: UI for tracking #1884

Closed
wants to merge 6 commits into from
Closed

Conversation

savan77
Copy link
Contributor

@savan77 savan77 commented Jul 10, 2020

This PR adds UI for tracking.

Motivation and context

The older PR for tracking was using older UI and wasn't compatible with new UI. This PR ported UI to the new UI. This is similar to what we had earlier. The only change is for Stop frame (Track Until) we are using a specific frame number rather than the Next Keyframe, etc since it is easier for users to say "track until next 50 or so frames". But its still there in the settings UI in case you want to use it.

Below are some screenshots.

tracking_1

tracking_2

tracking_3

How has this been tested?

It has been tested locally as well as on Onepanel platform.

Checklist

  • [x ] 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)
    I will update the documentation once it has been accepted.

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) 2020 Intel Corporation
#
# SPDX-License-Identifier: MIT

CC: @rushtehrani @nmanovic @TheNaman047

@savan77 savan77 requested a review from bsekachev as a code owner July 10, 2020 18:30
@coveralls
Copy link

coveralls commented Jul 10, 2020

Pull Request Test Coverage Report for Build 6519

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 742 unchanged lines in 29 files lost coverage.
  • Overall coverage decreased (-0.2%) to 64.988%

Files with Coverage Reduction New Missed Lines %
cvat/apps/dataset_manager/formats/mask.py 1 89.29%
cvat/apps/dataset_manager/formats/mot.py 1 94.74%
datumaro/datumaro/plugins/datumaro_format/converter.py 2 98.16%
datumaro/datumaro/plugins/tf_detection_api_format/extractor.py 2 88.68%
datumaro/datumaro/plugins/coco_format/importer.py 3 79.49%
cvat/apps/dataset_manager/formats/pascal_voc.py 4 60.0%
datumaro/datumaro/cli/util/project.py 4 26.92%
datumaro/datumaro/plugins/yolo_format/converter.py 4 89.72%
datumaro/datumaro/util/init.py 4 80.85%
datumaro/datumaro/components/converter.py 5 88.46%
Totals Coverage Status
Change from base Build 6382: -0.2%
Covered Lines: 11065
Relevant Lines: 16620

💛 - Coveralls

@nmanovic
Copy link
Contributor

@bsekachev , could you please look at the PR? Probably you want to merge it with minimal changes from @savan77 and after that polish on our side if it is necessary.

@bsekachev
Copy link
Member

@nmanovic Sure, will do it.

cvat-ui/src/actions/annotation-actions.ts Outdated Show resolved Hide resolved
cvat-ui/src/actions/annotation-actions.ts Outdated Show resolved Hide resolved
cvat-ui/src/actions/annotation-actions.ts Outdated Show resolved Hide resolved
cvat-ui/src/actions/annotation-actions.ts Outdated Show resolved Hide resolved
Comment on lines +27 to +60
const trackTypeOptions = [
{
label: "OpenCV Boosting",
value: "Boosting",
},
{
label: "OpenCV MIL",
value: "MIL",
},
{
label: "OpenCV KCF",
value: "KCF",
},
{
label: "OpenCV CSRT",
value: "CSRT",
},
{
label: "OpenCV MedianFlow",
value: "MEDIANFLOW",
},
{
label: "OpenCV TLD",
value: "TLD",
},
{
label: "OpenCV MOSSE",
value: "MOSSE",
},
{
label: "GOTURN",
value: "GOTURN",
},
]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's avoid hardcoding of tracker types on client side. I would suggest two options here:

  1. Get these types from the server
  2. Implement UI only for one of tracker as the initial version

In the future we want to be able to work with different trackers, implemented as serverless functions.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That server side function is not implemented yet but I think we should be able to add it easily as we move forward.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TheNaman047

It should be implemented before we merge this PR, since our users will have questions about new controls in UI, that are useless for them right now, because our server doesn't support tracking yet.

Copy link
Contributor Author

@savan77 savan77 Jul 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bsekachev As per our discussion with @nmanovic , this PR was supposed to be for UI only since you guys are implementing a serverless function for tracking. We can update UI assuming there is an API, let's say get_trackers_list, and make appropriate changes in the front-end. I understand we can't merge it until we have the backend. I suggest we merge this PR and PR for the serverless tracking function together, once we have it.

Copy link
Member

@bsekachev bsekachev Jul 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@savan77 Sure, this PR is for UI only. I mean UI shouldn't have hardcoded tracker types and display controls related with tracking by default (at this moment, till we haven't implemented server tracking). I think making temporary stubs (roughly speaking: const supportTracking = async (): boolean => false and const getTrackers = async (): any[] => []) is a suitable option). You do not need even make real server requests.

Copy link
Contributor Author

@savan77 savan77 Aug 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bsekachev can you check now? @TheNaman047 pushed a change which checks for at least one tracker to show the tracker settings.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@savan77 Sure, I will. But as I can see, we still have hardcoded trackers on UI (from OpenCV). Is it outdated code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bsekachev that's right. @TheNaman047 As we discussed, we should not show any trackers by default. We need to show tracker settings only if we get positive response from that API call. And show that trackers in the list, not the hard-coded once.
Please correct me if I am wrong. @bsekachev

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@savan77

Yes, there were two ideas in this thread above. The first is what you mentioned and the second is do not hardcode trackers on client side. UI should get these types from the server. Right now one of trackers is implemented as a nuclio serverless function and we might use it in the implementation.

I understand if it isn't your priority, on our side I am ready to modify the PR next week

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @bsekachev , that would be great since you have some ideas about this new serverless function.

@bsekachev
Copy link
Member

@savan77

Hi, thx for the PR, really appreciate it.
There are some minor code issues I found. Will test the PR better tomorrow.
One important issue is that tracker controls in UI are always visible, nevertheless our server doesn't support trackers at all right now. So, we need to ask server whether it supports tracking or not and display these elements dynamically. You can look at deep extreme cut implementation and see how it works in this case.

Please, contact me if you have any questions about our code

@savan77
Copy link
Contributor Author

savan77 commented Jul 13, 2020

Thanks @bsekachev

@TheNaman047 can you take a look at these comments and make appropriate changes?

@TheNaman047
Copy link

TheNaman047 commented Jul 13, 2020 via email

@bsekachev
Copy link
Member

@savan77 @TheNaman047

Hi, what are updates on the PR?

@TheNaman047
Copy link

Hi @bsekachev, Thanks for reviewing the code. Have corrected the recommended changes.

@bsekachev
Copy link
Member

bsekachev commented Jul 21, 2020

@TheNaman047

Thx, what have you decided about dinamic controls displaying? This issue is quite critical IMHO.

@nmanovic
Copy link
Contributor

nmanovic commented Aug 5, 2020

@savan77 , @TheNaman047 , @rushtehrani ,

I have added support for trackers on server: #1988. It is your turn now. Could you please help to finalise the PR and check that it works with SiamMask from the mentioned PR? I'm happy to help and answer questions.

@savan77
Copy link
Contributor Author

savan77 commented Aug 10, 2020

@nmanovic Thanks. We have been busy with one urgent piece.

Anyway, I think PR is good to go except for one change that @bsekachev requested. I will ask @TheNaman047 to take a look as soon as possible.

@mhe-wyze
Copy link

mhe-wyze commented Aug 12, 2020

Any follow up for this? @nmanovic @savan77

@savan77
Copy link
Contributor Author

savan77 commented Aug 13, 2020

We have made required changes. I will be testing and pushing them soon.

@nmanovic
Copy link
Contributor

@savan77 , it is great to hear! Do you have any estimation when it will be ready to merge?

@savan77
Copy link
Contributor Author

savan77 commented Aug 19, 2020

@savan77 , it is great to hear! Do you have any estimation when it will be ready to merge?

@nmanovic - @TheNaman047 has pushed required changes.

@savan77
Copy link
Contributor Author

savan77 commented Aug 19, 2020

@rushtehrani Thanks, just corrected those typos.

@nmanovic
Copy link
Contributor

@savan77 , I see at least one conflict. Could you please resolve it?

@bsekachev , could you please look at the current patch and comment?

@nmanovic
Copy link
Contributor

nmanovic commented Sep 2, 2020

@savan77 , as I discussed with Rush and Don, my team is going to implement the feature slightly different. Also the PR isn't ready and we have decided to close it. In any case thanks for the contribution. It gave us a lot of ideas and a ready to use prototype.

@nmanovic nmanovic closed this Sep 2, 2020
@mhe-wyze
Copy link

mhe-wyze commented Sep 2, 2020

Hi @nmanovic , thanks for your update, I was recently looking at this branch because the truly object tracking function by AI models would largely help accelerate the annotation speed for our project. Today I saw you closed it, is that meant this function is still ongoing, haven't finished yet, probably your team would work more on the new design later, right?

@nmanovic
Copy link
Contributor

nmanovic commented Sep 3, 2020

@mhe-wyze , it is right. Recently we have added support for the feature as a serverless function. @bsekachev is going to add UI for tracking in coming months (probably significantly early).

@rushtehrani rushtehrani deleted the tracking_ui branch January 9, 2021 05:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants