can it be as static_assert ?

Answering question, no, it failed when I tried.

But I decided that, as I've already been using enable_if semantics, this condition should be there, too

Also, there were warnings on Windows compilers about the next saturate function overload, so I rewrote it with enable_ifs, too

static_cast by code style(?)

Yes, I think you're right. Just really don't like to write it.
Maybe there are no such strict conventions in OCV, but you're still right :)

it is the place where other reviewers will pay attention, personally i dislike such writing long-symbol cast too, but it's still strong recommendation

destruct throws error?

I checked code and found root cause of exception

    // Pull messages from the final queue to ensure completion
    Cmd cmd;
    while (!cv::util::holds_alternative<Stop>(cmd))
    {
        m_out_queue.pop(cmd);
    }
    GAPI_Assert(cv::util::holds_alternative<Stop>(cmd));   <----

And

1. Assert looks redundant, because while-loop won't breaks otherwise
2. this may be solved by more simplest way then using std::uncaught_exception
   a) separate stop() on stop() & wait_stop/shutdown(), and just call stop() in ~dtor because it looks like you should not extracts some cmd (because currently we're dropping them anyway) OR trying to wait it several cycles, then big WARNING printed
   b) do not throw Assert exception at all

From my perspective std::uncaught_exception is redundant and stirred ups and should be used in more dead-ended situations. But stop should not throw anything

I think your comment is highly reasonable, firstly about freeing destruction from exceptions: I'd rather dive a bit deeper & solve as many rootcauses as possible than simply cover all with try-catch.

Secondly, I like this stop() separation suggestion.

Though, there are much more places where destructor can fall over.
The most obvious is assert in push() of concurrent_bounded_queue:

   if (m_capacity && m_capacity == m_data.size()) {
        // if there is a limit and it is reached, wait
        m_cond_full.wait(lock, [&](){return m_capacity > m_data.size();});
        GAPI_Assert(m_capacity > m_data.size());
    }

and maybe some others.

@dmatveev what do you think on this destructor issue?

@OrestChura i see you point, but: from my perspective bounded_queue should not throws too because std::conditional_variable here retain its postcondition after .wait - so we do not need to debug standard c++ library and this check looks impossible according to bounded_queue design. So this throwing exception reason MUST be predictable, because this code doesn't interact with some user input or depends some OS/IO/RAM primitives setting but all behavior ensured by STD. I mean that it cannot throw sporadically and 100% determined from current code logic from 100% determined cases.
SO, there are should have been unit test for that "case" which ensure that exception must or must not to ensure guarantee that bounded_queue is consistent at all. But I'm pretty sure that it is useless here

What's about other exception: std::bad_alloc and so on - they are uncontrollable/unpredictable from us usually and/or based on user input or other system settings and SHOULD be checked in appropriate places OR ignored and falls into destructor and let program terminate in usual way, If it doesn't contradict with current policy

Example of predictable & controllable behavior:

try {
cin >> size; // user input `-1`
char* new char [size];  // usually throws std::bad_alloc on `-1` 
} catch (...)
{
cerr << "Too much size requested: " << size << std::endl;
}

Example of non predictable behavior

std::string aaa = "aaa";
foo(aaa);
foo (std::string bbb)  <---- copy may throw

The second example usually in not handled in most common applications and should be ignored

In result i assume that coverity doesn't dive into STD code and doesn't check throwing from vector push and so on and it's limited by application code only

i thinks stop should not throw

👍🏻

reject for double only? in this case i think we can change SFINAE from std::is_floating_point<SRC>::value to is_same<float>

For this point, I assumed that if we utilize SFINAE there will be non-informative compile error; in the case of Assert, it will be clear why and where the problem is.
So I'd prefer leaving Assert

Any kind of error is better than no error, i agree

But when you spend ~30min to compile entire application and then got runtime error (or not got which is worse) about error which were managed to be found at compile time then fix it and spend 30 minutes again - it's disappointing.

So compile-time error should be found at compile time, I think. If you worried about nasty compilation message please consider static_assert(..., "Something horrible") here

Makes sense. Made it static_assert, and added it in some other overloads too

because alpja & beta are floating point - i do not think it is right to compare them with straight to integer 1 & 0 is correct across using epsilon

fixed

But why only logic_error ?

fixed