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

Outside property not used for rectangle tracks at CVAT for Images 1.1 #2339

Closed
2 tasks done
georkap opened this issue Oct 21, 2020 · 1 comment · Fixed by #2345
Closed
2 tasks done

Outside property not used for rectangle tracks at CVAT for Images 1.1 #2339

georkap opened this issue Oct 21, 2020 · 1 comment · Fixed by #2345
Assignees
Labels
bug Something isn't working
Milestone

Comments

@georkap
Copy link

georkap commented Oct 21, 2020

My actions before raising this issue

We use interpolation of rectangles to annotate objects in annotation mode. Occasionally a rectangle is not visible so we mark it as "outside". The dumped annotation xml using "CVAT for Images 1.1" still includes entries for the "outside" rectangles at the frames where they were marked as "outside" without any indication that they are actually outside. Using CVAT version v.1.1.0

Related: #1620 and #1729

Expected Behaviour

The expected behaviour is to exclude entries for the rectangles that are marked as "outside" (as was the case with "hidden" at v.0.6.1).

Current Behaviour

As a test, we dumped the annotations using the "YOLO 1.1" format directly and the "outside" rectangles were excluded. Dumping with "CVAT for Videos 1.1" provides an "outside" attribute to the resulting xml however the output format of the xml is incompatible with the post-processing steps we developed using the previous CVAT version.

Possible Solution

Steps to Reproduce (for bugs)

  1. Create a new task
  2. Draw new Rectangle as Track (doesn't matter if 2-points or 4-points)
  3. Mark the rectangle at a random frame as "outside"
  4. Save
  5. Dump annotations as "CVAT for Images 1.1"

Context

I can't be sure if it a bug or desired behaviour introduced in the new version, however the usability of "hidden" from version 0.6.1 to hide object instances when annotating with interpolation mode cannot be reproduced neither with "hidden" nor with "outside".

Your Environment

not relevant

Next steps

You may join our Gitter channel for community support.

@nmanovic nmanovic added the bug Something isn't working label Oct 21, 2020
@nmanovic nmanovic added this to the 1.2.0-alpha milestone Oct 21, 2020
@nmanovic
Copy link
Contributor

@georkap , thanks for the report. @zhiltsov-max , could you please look at the issue?

zhiltsov-max added a commit that referenced this issue Apr 19, 2024
…ts (#7669)

<!-- Raise an issue to propose your change
(https://github.com/opencv/cvat/issues).
It helps to avoid duplication of efforts from multiple independent
contributors.
Discuss your ideas with maintainers to be sure that changes will be
approved and merged.
Read the [Contribution
guide](https://opencv.github.io/cvat/docs/contributing/). -->

<!-- Provide a general summary of your changes in the Title above -->

### Motivation and context
<!-- Why is this change required? What problem does it solve? If it
fixes an open
issue, please link to the issue here. Describe your changes in detail,
add
screenshots. -->

Main Issue: #7571 
Related Issue: #2339 

I've reproduced the issue mentioned in #7571 when exporting and
importing annotations using both the Datumaro and Coco 1.0 formats.
Specifically, the "Switch outside" attribute isn't being applied as
expected. After some investigation, I pinpointed the root cause to be
the absence of the "outside" attribute in the exported annotations.

To address this, I've made adjustments to the binding.py file to bypass
the track_id during annotation import. This modification appears to
solve the issue regarding the "Switch outside" attribute. However, it
introduces a new concern: the potential loss of information, including
keyframes and track_id.

While this workaround offers a temporary fix, I'm contemplating a more
holistic approach that entails properly handling the "outside" attribute
during both the export and import processes of annotations. This method
could preserve the integrity of the annotations while ensuring the
functionality of the "Switch outside" attribute.

I'm reaching out for feedback or suggestions on my proposed solution. Is
there a preference for one of these approaches, or might there be
another avenue I haven't considered?

Looking forward to your insights.

### Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply.
If an item isn't applicable for some reason, then ~~explicitly
strikethrough~~ the whole
line. If you don't do that, GitHub will show incorrect progress for the
pull request.
If you're unsure about any of these, don't hesitate to ask. We're here
to help! -->
- [x] I submit my changes into the `develop` branch
- [x] I have created a changelog fragment <!-- see top comment in
CHANGELOG.md -->
- [ ] I have updated the documentation accordingly
- [x] I have added tests to cover my changes
- [x] I have linked related issues (see [GitHub docs](

https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword))
- [ ] I have increased versions of npm packages if it is necessary

([cvat-canvas](https://github.com/opencv/cvat/tree/develop/cvat-canvas#versioning),

[cvat-core](https://github.com/opencv/cvat/tree/develop/cvat-core#versioning),

[cvat-data](https://github.com/opencv/cvat/tree/develop/cvat-data#versioning)
and

[cvat-ui](https://github.com/opencv/cvat/tree/develop/cvat-ui#versioning))

### License

- [x] I submit _my code changes_ under the same [MIT License](
https://github.com/opencv/cvat/blob/develop/LICENSE) that covers the
project.
  Feel free to contact the maintainers if that's a concern.

---------

Co-authored-by: Maxim Zhiltsov <zhiltsov.max35@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants