G-API planar kernels by rgarnov · Pull Request #14917 · opencv/opencv

rgarnov · 2019-06-27T13:57:37Z

build_gapi_standalone:Linux x64=ade-0.1.1d
build_gapi_standalone:Win64=ade-0.1.1d
build_gapi_standalone:Mac=ade-0.1.1d
build_gapi_standalone:Linux x64 Debug=ade-0.1.1d

rgarnov · 2019-06-27T15:05:49Z

@dbudniko please take a look

# Conflicts: # modules/gapi/test/common/gapi_core_tests.hpp # modules/gapi/test/common/gapi_imgproc_tests.hpp # modules/gapi/test/common/gapi_imgproc_tests_inl.hpp

dbudniko · 2019-07-02T13:59:16Z

@rgarnov @alalek , please review the latest fixes.

modules/gapi/include/opencv2/gapi/core.hpp

modules/gapi/include/opencv2/gapi/imgproc.hpp

rgarnov · 2019-07-02T16:11:16Z

Looks good

alalek

Instead of playing with size, you can split planes completely:

planeB, planeG, planeR

alalek · 2019-07-02T16:15:56Z

modules/gapi/include/opencv2/gapi/core.hpp

+
+@note Function textual ID is "org.opencv.core.transform.resizeP"
+
+@param src input image, must be of @ref CV_8UC3 type;


planar image
CV_8UC3

CV_8UC3 means interleaved image. So planar is source of confusion here.
planar is src1, src2 and src3 with CV_8UC1 type.

What is the main difference between resize and resizeP? Missing fx, fy?
Do we really need this entry point?

How do you want to downscale image by 2 with odd source size?
9x9 => 4.5 x 4.5 as 4x4 - is not 2x downscaling without extra information.

The main difference is that resizeP has GMatP ("planar GMat") as input and as output so the engine can behave correctly.
This description definitely should be changed to reflect planar image memory layout (three planes laying in the memory contiguously), so the image height should be plane_height*plane_number, image type is CV_8UC1 and so on. Maybe planar images deserve some special chapter?

alalek · 2019-07-02T16:20:46Z

modules/gapi/include/opencv2/gapi/imgproc.hpp

+The function converts an input image from NV12 color space to RGB.
+The conventional ranges for Y, U, and V channel values are 0 to 255.
+
+Output image must be 8-bit unsigned planar 3-channel image @ref CV_8UC3.


planar 3-channel

CV_8UC3 is interleaved 3-channel.

I've upadted doxygen comments. I suggest to merge it as is to move forward.

dmatveev · 2019-07-02T18:40:56Z

Instead of playing with size, you can split planes completely:
planeB, planeG, planeR

For sure, and this is how our preprocessing works now on CPU. We do use a "split3" thing with its output Mats redirected properly to form a 3-channel buffer in the CHW layout.

split3 with three distinct outputs has both advantages (e.g. we can compose the output plane order for free in a way we need) and disadvantages (it doesn't put any restrictions on its output memory chunks - so those could be three different bufferfs).

On some platform which we currently enable with G-API, the operations like color conversions and resize operate with planar images natively. However, that operations assume only a single data pointer (with a fixed offset between the planes), not three different ones. So from the API perspective it is safer to introduce "planar" image type there rather than simulate it with three data objects pointing to the same memory chunk

alalek · 2019-07-02T19:41:57Z

3-channel color image:

interleaved: 2D matrix {height, width} with CV_8UC3 element type
your concatenated planar: 3D matrix {channels, height, width} with CV_8UC1 element type

Not sure why you need some strange GMatP workarounds with implicit number of channels (plane_height*plane_number).
Regular 3D matrix is able properly handle this layout with explicit number of channels in size[0].

Main problem of 3D approach is NV12 storage format, where planes are not "equal".

dbudniko · 2019-07-04T10:11:09Z

@dmatveev please approve. @alalek is waiting for it to merge.

dmatveev · 2019-07-04T12:43:54Z

Not sure why you need some strange GMatP workarounds with implicit number of channels (plane_height*plane_number).

It is mainly an API contract. All our existing kernels which work with GMats in their API do not expect planar input, so we decided to forbid passing possibly-planar data there to avoid issues and confusion. GMat/GMatP clearly separates kernels on a type level.

dmatveev · 2019-07-04T12:46:26Z

Regular 3D matrix is able properly handle this layout with explicit number of channels in size[0].

This is a good point, BTW! Probably later we'll adjust API to use multi-dimensional matrices for the planar case.

dmatveev

👍 thanks!

dmatveev · 2019-07-06T23:24:08Z

Thanks!

* master: (74 commits) Merge pull request opencv#14917 from rgarnov:gapi_planar_kernels Fixed initUndistortRectifyMap AVX2 implementation Merge pull request opencv#14959 from dvd42:onnx_clip videoio: eliminate build warnings (clang) ts: runtime check for misused 'optional' test data files 3rdparty(itt): support AARCH64 tensroflow support maxpoolgrad Fix blob detector insertion sort Fix crash, add assert and test Merge pull request opencv#14946 from andrey-golubev:obj_not_ref re-enable CPU_BASELINE=FP16 on Armv7 platform Merge pull request opencv#14828 from armenpoghosov:parmen_RANSACPointSetRegistrator_getSubset_disaster_cleanup Merge pull request opencv#14916 from terfendail:wsignmask_deprecated core: evaluate CV_Error() parameters during static scans dnn: fix build with Vulkan Merge pull request opencv#14936 from StefanBruens:crosscorr_cleanup Explicitly default operator= for Vec<T, n> Fix JS sample of dnn 3rdparty: TBB version 2018u1 => 2019u8 cmake: support rpath-link linker option ...

G-API planar kernels (opencv#14917) * Added resizeP with tests * NV12 planar filters * fix warnings in ResizeP test * fix out mat ocv warning * sz_on - > sz rename * cpu tests new signature * try to fix resizeP test * trailing spaces remove * doxygen doc fixed * doxygen minor fix * more doxygen fixes * Doxygen corrected and extended after review.

Added resizeP with tests

5e39c81

Dmitry Budnikov added 9 commits June 28, 2019 17:54

NV12 planar filters

1c761e0

Merge remote-tracking branch 'main/master' into gapi_planar_kernels

41b28d5

# Conflicts: # modules/gapi/test/common/gapi_core_tests.hpp # modules/gapi/test/common/gapi_imgproc_tests.hpp # modules/gapi/test/common/gapi_imgproc_tests_inl.hpp

fix warnings in ResizeP test

7137786

fix out mat ocv warning

2db60da

sz_on - > sz rename

17ea765

cpu tests new signature

e66146c

try to fix resizeP test

9eb6290

trailing spaces remove

7cf99d9

doxygen doc fixed

6df9900

doxygen minor fix

2ce88d7

rgarnov commented Jul 2, 2019

View reviewed changes

modules/gapi/include/opencv2/gapi/core.hpp Outdated Show resolved Hide resolved

modules/gapi/include/opencv2/gapi/imgproc.hpp Outdated Show resolved Hide resolved

more doxygen fixes

772cbbc

alalek reviewed Jul 2, 2019

View reviewed changes

Doxygen corrected and extended after review.

856e3e0

dmatveev approved these changes Jul 4, 2019

View reviewed changes

alalek assigned dmatveev Jul 4, 2019

alalek merged commit ad49138 into opencv:master Jul 4, 2019


		@note Function textual ID is "org.opencv.core.transform.resizeP"

		@param src input image, must be of @ref CV_8UC3 type;

Uh oh!

Conversation

rgarnov commented Jun 27, 2019 • edited by alalek Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rgarnov commented Jun 27, 2019

Uh oh!

dbudniko commented Jul 2, 2019

Uh oh!

Uh oh!

Uh oh!

rgarnov commented Jul 2, 2019

Uh oh!

alalek left a comment

Choose a reason for hiding this comment

Uh oh!

alalek Jul 2, 2019

Choose a reason for hiding this comment

Uh oh!

rgarnov Jul 2, 2019

Choose a reason for hiding this comment

Uh oh!

alalek Jul 2, 2019

Choose a reason for hiding this comment

Uh oh!

dbudniko Jul 3, 2019

Choose a reason for hiding this comment

Uh oh!

dmatveev commented Jul 2, 2019

Uh oh!

alalek commented Jul 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dbudniko commented Jul 4, 2019

Uh oh!

dmatveev commented Jul 4, 2019

Uh oh!

dmatveev commented Jul 4, 2019

Uh oh!

dmatveev left a comment

Choose a reason for hiding this comment

Uh oh!

dmatveev commented Jul 6, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

rgarnov commented Jun 27, 2019 •

edited by alalek

Loading

alalek commented Jul 2, 2019 •

edited

Loading