Skip to content

GAPI: Add OAK backend#20785

Merged
alalek merged 46 commits intoopencv:4.xfrom
smirnov-alexey:as/oak_backend
Jan 17, 2022
Merged

GAPI: Add OAK backend#20785
alalek merged 46 commits intoopencv:4.xfrom
smirnov-alexey:as/oak_backend

Conversation

@smirnov-alexey
Copy link
Copy Markdown
Contributor

@smirnov-alexey smirnov-alexey commented Oct 1, 2021

Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

  • I agree to contribute to the project under Apache 2 License.
  • To the best of my knowledge, the proposed patch is not based on a code under GPL or other license that is incompatible with OpenCV
  • The PR is proposed to proper branch
  • There is reference to original bug report and related work
  • There is accuracy test, performance test and test data in opencv_extra repository, if applicable
    Patch to opencv_extra has the same branch name.
  • The feature is well documented and sample code can be built with the project CMake
force_builders=Custom,Custom Win,Custom Mac
build_gapi_standalone:Linux x64=ade-0.1.1f
build_gapi_standalone:Win64=ade-0.1.1f
build_gapi_standalone:Mac=ade-0.1.1f
build_gapi_standalone:Linux x64 Debug=ade-0.1.1f

Xbuild_image:Custom=centos:7
Xbuildworker:Custom=linux-1
build_gapi_standalone:Custom=ade-0.1.1f

build_image:Custom=ubuntu-openvino-2021.4.2:20.04
build_image:Custom Win=openvino-2021.4.2
build_image:Custom Mac=openvino-2021.4.2

test_modules:Custom=gapi,python2,python3,java
test_modules:Custom Win=gapi,python2,python3,java
test_modules:Custom Mac=gapi,python2,python3,java

buildworker:Custom=linux-1
test_opencl:Custom=OFF
test_bigdata:Custom=1
test_filter:Custom=*

@smirnov-alexey
Copy link
Copy Markdown
Contributor Author

@dmatveev @TolyaTalamanov @rgarnov fyi. It's still WIP though

@smirnov-alexey
Copy link
Copy Markdown
Contributor Author

@dmatveev @TolyaTalamanov @AsyaPronina @rgarnov please, take a look. This is rather a draft version and still need some polishing even for a hard-coded pipeline. Still, I would appreciate any feedback. Am I moving to the right direction here?

@smirnov-alexey
Copy link
Copy Markdown
Contributor Author

The issue with corrupted frames still persists though

Copy link
Copy Markdown
Contributor

@dmatveev dmatveev left a comment

Choose a reason for hiding this comment

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

Good to know it's alive, but it is far even from an experimental backend yet.

What I'd consider as a bare minimum for merge:

  1. Generic handling of DAI operations via our kernel interface (let it be NOT public for now)
  2. Generic handling of camera/non-camera case + tests for these two configurations

Inference, CV ops, etc. can be added atop of this baseline and once the fundamental issues (1) and (2) are solved.

Comment on lines +109 to +112
namespace detail {
template<> struct CompileArgTag<gapi::oak::ColorCameraParams> {
static const char* tag() { return "gapi.oak.colorCameraParams"; }
};
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If we have camera here as a distinct object, should its setup be passed as a graph compile arg?

Actually, when the graph is compiled there's no idea whether a file or a camera will be used as input.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I'd leave it as is for now. Non-camera input will be introduced later in a separate PR

namespace oak {

enum class OAKFrameFormat {
BGR = 0,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

MediaFrame has these enums already,

Copy link
Copy Markdown
Contributor Author

@smirnov-alexey smirnov-alexey Dec 8, 2021

Choose a reason for hiding this comment

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

There are more color formats supported by OAK, should we stick to BGR and NV12 only?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

we should extend MediaFrame enums then. :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Change to cv::MediaFormat

@dmatveev dmatveev modified the milestones: 5.0, 4.6.0 Dec 24, 2021
Comment on lines +552 to +553
*in = &(videoEnc->input);
*out = &(videoEnc->bitstream);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

but finally it looks here as intended :)


GAPI_OAK_KERNEL(GOAKSobelXY, cv::gapi::oak::GSobelXY) {
static void put(const std::unique_ptr<dai::Pipeline>& pipeline,
const std::tuple<int, int>& camera_wh,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why do you need this in every kernel?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Some of the DAI operations need to set max resolution size

cv::Size(static_cast<int>(oak_frame->getWidth()),
static_cast<int>(oak_frame->getHeight())),
cv::MediaFormat::NV12,
std::move(oak_frame->getData()));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

but why still not to move oak_frame by itself?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

What about VectorRef case below? I think we should be consistent here

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

could you describe what is VectorRef case (why we introduced it here) and why MediaFrame is not enough?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We use VectorRef for encoding - it's operation's output. VectorRef is basically a vector while MediaFrame is more flexible type. This logic could also be extended in the future for other types like cv::Mat, Opaque, etc

size_t out_counter = 0;
for (const auto& d : outs_data)
{
for (const auto& nh : nodes)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

And here you can look at d->inNodes() (should be only one producer)

@smirnov-alexey
Copy link
Copy Markdown
Contributor Author

@dmatveev @sivanov-work please, take a look

Copy link
Copy Markdown
Contributor

@sivanov-work sivanov-work left a comment

Choose a reason for hiding this comment

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

LGTM

cv::Size(static_cast<int>(oak_frame->getWidth()),
static_cast<int>(oak_frame->getHeight())),
cv::MediaFormat::NV12,
std::move(oak_frame->getData()));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

could you describe what is VectorRef case (why we introduced it here) and why MediaFrame is not enough?

Comment on lines +40 to +41
cv::MediaFrame::View::Strides{static_cast<long unsigned int>(m_sz.width),
static_cast<long unsigned int>(m_sz.height)}};
Copy link
Copy Markdown
Contributor

@dmatveev dmatveev Jan 13, 2022

Choose a reason for hiding this comment

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

Stride is a distance between every row in a plane, in bytes.
If passing width looks legit here for Y plane, how height could become a stride for UV plane?

@sivanov-work @rgarnov am I wrong here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

That worked somehow, but you're right. Changed to width and width for both planes

m_priv(new OAKMediaAdapter::Priv(sz, fmt, y_ptr, uv_ptr)) {};

MediaFrame::View OAKMediaAdapter::access(MediaFrame::Access access) {
return m_priv->access(access);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Its debatable but so far OAKMediaAdapter itself may be private so no extra PIMPLing required.


// 2. Link output nodes to XLinkOut nodes
size_t out_counter = 0;
for (const auto& nh : out_nodes) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

there's no strict defined order in out_nodes right?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It's aligned with the backend's out_data and is being used in that aligned way

// 3. Link internal nodes to their parents
for (const auto& nh : inter_nodes) {
// Input nodes in OAK doesn't have parent operation - just camera (for now)
if (std::find(in_nodes.begin(), in_nodes.end(), nh) == in_nodes.end()) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This search is linear too. Also why do you need this check here at all? Is your inter_nodes incorrect?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Done

@smirnov-alexey smirnov-alexey changed the title WIP: GAPI: Add OAK backend GAPI: Add OAK backend Jan 17, 2022
Copy link
Copy Markdown
Contributor

@dmatveev dmatveev left a comment

Choose a reason for hiding this comment

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

I believe it is ok to merge now

@alalek alalek merged commit f2d5d6d into opencv:4.x Jan 17, 2022
@alalek alalek mentioned this pull request Feb 22, 2022
a-sajjad72 pushed a commit to a-sajjad72/opencv that referenced this pull request Mar 30, 2023
GAPI: Add OAK backend

* Initial tests and cmake integration

* Add a public header and change tests

* Stub initial empty template for the OAK backend

* WIP

* WIP

* WIP

* WIP

* Runtime dai hang debug

* Refactoring

* Fix hang and debug frame data

* Fix frame size

* Fix data size issue

* Move test code to sample

* tmp refactoring

* WIP: Code refactoring except for the backend

* WIP: Add non-camera sample

* Fix samples

* Backend refactoring wip

* Backend rework wip

* Backend rework wip

* Remove mat encoder

* Fix namespace

* Minor backend fixes

* Fix hetero sample and refactor backend

* Change linking logic in the backend

* Fix oak sample

* Fix working with ins/outs in OAK island

* Trying to fix nv12 problem

* Make both samples work

* Small refactoring

* Remove meta args

* WIP refactoring kernel API

* Change in/out args API for kernels

* Fix build

* Fix cmake warning

* Partially address review comments

* Partially address review comments

* Address remaining comments

* Add memory ownership

* Change pointer-to-pointer to reference-to-pointer

* Remove unnecessary reference wrappers

* Apply review comments

* Check that graph contains only one OAK island

* Minor refactoring

* Address review comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants