Skip to content

C
Cvat

疯人忠 / Cvat

通知 1
Star 0
Fork 0
C
Cvat

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 09 8月, 2023 4 次提交
  3. 08 8月, 2023 1 次提交
  5. 07 8月, 2023 4 次提交
  7. 03 8月, 2023 1 次提交
    • R
      Add auto-annotation support to SDK and CLI (#6483) · 1c0a49fc
      由 Roman Donchenko 提交于 
      Introduce a `cvat-sdk auto-annotate` command that downloads data for a task,
then runs a function on the local computer on that data, and uploads
resulting annotations back to the task.

To support this functionality, add a new SDK module,
`cvat_sdk.auto_annotation`, that contains an interface that the
functions must follow, and a driver that applies a function to a task.

This will let users easily annotate their tasks with custom DL models.
      1c0a49fc
  9. 31 7月, 2023 4 次提交
  11. 28 7月, 2023 2 次提交
    • B
      Optimized client side rendering, improved previews code (#6543) · 844a72b8
      由 Boris Sekachev 提交于 
      <!-- 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
* drawImage is about x10+ times faster than putImageDate
* unified interface on cvat-core
* yes, there is still some time necessary to convert ImageData to
ImageBitmap

Before:
<img width="302" alt="image"
src="https://github.com/opencv/cvat/assets/40690378/8f59f24d-7f3e-4428-8412-f11440247d6e">

After:
<img width="282" alt="image"
src="https://github.com/opencv/cvat/assets/40690378/f5021278-d14b-42c9-8e39-1f7b6122a16c">

### How has this been tested?
<!-- Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc. -->

### 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
- [ ] I have added a description of my changes into the
[CHANGELOG](https://github.com/opencv/cvat/blob/develop/CHANGELOG.md)
file
- [ ] I have updated the documentation accordingly
- [ ] I have added tests to cover my changes
- [ ] 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))
- [x] 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.
      844a72b8
    • R
      Revamp the progress reporting API (#6556) · 4b86439d
      由 Roman Donchenko 提交于 
      There are several problems with how progress reporting is handled in the
SDK, both on the interface and implementation level:

* The user is supposed to know, for a given function, which units it
will report progress in. This is unnecessary coupling and prevents us
from switching to different units, or to have several progress bars
using different units.

* To create a TqdmProgressReporter, you have to create a tqdm instance,
which immediately draws a progress bar. This works poorly if the
function prints any log messages before the progress actually starts.

* There's no easy way to automatically call `finish` on a progress bar,
so some functions don't (for example, `Downloader.download_file`). This
can cause unexpected output, since tqdm will refresh the progress bar in
a background thread (possibly after we've already printed something
else).

* `iter` is basically broken, because it divides by `period`, which is 0
in all current implementations.

* Even ignoring that, it's hard to use correctly, because you need to
manually call `finish` in case of an exception.

* `split` is not implemented and not used.

* `StreamWithProgress.seek` assumes that the progress bar is at 0 at the
start, and so does `ProgressReporter.iter`. The former also works
incorrectly if the second argument is not `SEEK_SET`.

Fix these problems by doing the following:

* Add a new `start2` method which accepts more parameters. The
default implementation calls `start`, so that if a user has implemented
the original interface, it'll keep working.

* Add a `DeferredTqdmProgressReporter` that accepts tqdm parameters instead of
a tqdm instance, and only creates an instance after `start2` is called.
Use it where `TqdmProgressReporter` was used before. The old
`TqdmProgressReporter` is kept for compatibility, but it doesn't support
any `start2` arguments other than those supported by the original
`start`.

* Add a `task` context manager, which automatically calls `start2` and
`finish`. Use it everywhere instead of explicit `start`/`finish` calls.
Remove `start`/`finish` calls from `StreamWithProgress` and `iter`.

* Implement basic assertions to ensure that `start2` and `finish` are
used correctly.

* Remove `period` and `split`.

* Rewrite `StreamWithProgress.seek` and `ProgressReporter.iter` to use
relative progress reports.

These changes should be backwards compatible for users who pass
predefined or custom progress reporters into SDK functions. They are not
backwards compatible for users who try to use progress reporters
directly (e.g. calling `start`/`finish`). I don't consider that a
significant issue, since the purpose of the `ProgressReporter` interface
is for the user to get progress information from the SDK, not for them
to use it in their own code.

Originally developed for #6483.
      4b86439d
  13. 27 7月, 2023 9 次提交
  15. 25 7月, 2023 4 次提交
  17. 24 7月, 2023 3 次提交
  19. 22 7月, 2023 1 次提交
    • M
      Extend cleaning for downloaded file names (#6492) · 9659f828
      由 Maxim Zhiltsov 提交于 
      Control characters in filenames may conflict with the Content-Disposition header
value restrictions, as it needs to include the downloaded file name. The problem is
that many tools (including sendfile) just check for ascii/unicode conversion,
while there are also ascii chars that can't be used.
Ref: RFC 8178

This PR adds extra cleanup for downloaded file names.

Added a custom replacement for the sendfile() function
      9659f828
  21. 21 7月, 2023 4 次提交
  23. 20 7月, 2023 3 次提交