Move G-API to opencv_contrib or into a separate repository at github/opencv about opencv HOT 1 OPEN

Hi Vadim, good points, let's have a look on those:

it does not look connected or integrated with other parts

I didn't knew you was actually OK with adding dependencies onto G-API within other modules. If so, the DNN's preprocessing routine may be a very good starting point, I'd have a look on that. There's others, for sure.

It uses different API for video capturing beyond VideoCapture/VideoWriter

Not really, the VideoCapture is the way to go in 90% of cases. It is just wrapped under GCaptureSource which we use the most. There are other sources exist for sure - a GStreamer and OneVPL one, but they're not promoted actively. If 5.0 is the time to scatter stones break things, I'd better review how this work can be incorporated into VideoCapture so we could stick to this one interface.

it uses different API for inferencing

Yeah we'd love to accept a DNN-based implementation of infer<> :) Arguably not a big deal though, "hold by beer".. Yes, what's on us is that we still haven't opened a formal feature request on DNN to provide information about the model - the one we need to maintain the graph contracts, but fundamentally there's no other blockers.

it reoptimizes some basic image processing operations without contributing it back to imgproc

It is applicable only to the Fluid set of operators and it is exactly what I mentioned on call - if the new CPU hal becomes ROW-based, then 1) all classic imgproc and core functions could leverage our work 2) we'd take kernels all from the same place.

It uses quite different coding style

G-API is initially written according to https://github.com/opencv/opencv/wiki/Coding_Style_Guide - so if there's any formal linter throwing warnings on the coding style let's see what we can do. Certainly there are bits which don't fall into the common style, but it is not the public API in the most cases (of course, with few exceptions). So I'd appreciate particular examples here to understand the trend.

It's quite heavy.

How do you measure heavy? Heavy how? Note G-API currently covers functionality of multiple OpenCV modules in one. We take care of the test execution time here, for example. As documented on wiki, some API- and component-level clean-ups were planned for 5.0 (where we can break stuff by removing the APIs). Binary size? We can look at. What else? Please define a clear criteria here.

I will comment on the rest & come-up with some examples (and more) later this week.

from opencv.