Skip to content

C
Cvat

疯人忠 / Cvat

通知 1
Star 0
Fork 0
C
Cvat

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 06 9月, 2023 5 次提交
  3. 05 9月, 2023 4 次提交
  5. 04 9月, 2023 1 次提交
  7. 02 9月, 2023 1 次提交
  9. 29 8月, 2023 1 次提交
  11. 25 8月, 2023 3 次提交
  13. 24 8月, 2023 3 次提交
  15. 23 8月, 2023 3 次提交
  17. 22 8月, 2023 2 次提交
  19. 21 8月, 2023 2 次提交
  21. 20 8月, 2023 1 次提交
  23. 15 8月, 2023 1 次提交
  25. 11 8月, 2023 5 次提交
  27. 10 8月, 2023 1 次提交
  29. 09 8月, 2023 3 次提交
  31. 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
  33. 31 7月, 2023 2 次提交
  35. 28 7月, 2023 1 次提交
    • 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