Maybe we don't need multiple callbacks? Just allowing to set one callback would also allow to customize it according to user's needs: write to multiple locations, filter by level, etc.

I was looking at the logging facilities in Qt: https://doc.qt.io/qt-6/qtlogging.html#qInstallMessageHandler - it is quite simple and customizable.

Maybe we don't need multiple callbacks? Just allowing to set one callback would also allow to customize it according to user's needs: write to multiple locations, filter by level, etc.

From my experience, libraries and applications that integrate OpenCV often do so across many levels and involving many components. Take torchvision as example.

It is for this reason that I think, each downstream library, and the user application itself, should be entitled to one (and only one) callback registration, so that if they have an urgent need to be self-aware (e.g. to know that something went wrong deep inside OpenCV or one of its third-party dependencies, e.g. video), they have the means to do that, and it wouldn't cause other layers' callback registration to become clobbered.

I agree that any single layer (library or app) that wants multiple callbacks for themselves should handle those details within their own callback handler.

If we are concerned about mutex and unordered_set (and pitfalls of locking / blocking), I have an idea of allowing for a fixed-size hash table (say, 16 entries), and use atomics to get around locking. I can share some code in the next few days. (Not as a PR, I'll probably just share a link to my personal branch.)

Another major question is, whether the callback should receive a single fully-formatted (concatenated) string, or should it be entitled to receive the individual fields. Not receiving the individual fields makes filtering quite difficult. However, I'm also concerned about ABI breakage.

Thank you for picking up this work @kinchungwong!

Another major question is, whether the callback should receive a single fully-formatted (concatenated) string, or should it be entitled to receive the individual fields. Not receiving the individual fields makes filtering quite difficult.

I'm not sure what constitutes a "field", but the loglevel should definitely be part of the callback. Basically as a user I'd ideally want to write something simple like this:

void myLogCallback(cv::utils::logging::LogLevel level, std::string msg,
                   const char* func, const char* file, int line)
{
    switch(level)
    {
        case cv::utils::logging::LOG_LEVEL_ERROR:
            spdlog::error("[{}:{}] {}", file, line, msg);
            break;
        case cv::utils::logging::LOG_LEVEL_WARNING:
            spdlog::warn("[{}:{}] {}", file, line, msg);
            break;
        case cv::utils::logging::LOG_LEVEL_INFO:
            spdlog::info("[{}:{}] {}", file, line, msg);
            break;
        default:
            spdlog::debug("[{}:{}] {}", file, line, msg);
            break;
    }
}

int main()
{
    // ...
    cv::utils::logging::setLogCallback(myLogCallback);
    // ...
}

If the func/file/line make things more complicated, then I don't need that - not sure if OpenCV even has those "fields". Just the loglevel and message is fine too.

void myLogCallback(cv::utils::logging::LogLevel level, std::string msg,
const char* func, const char* file, int line)

@patrikhuber : It does, refer to writeLogMessageEx in logger.hpp

Update: I have reworked this PR into the new design. Refer to PR description or commit comment. I believe this design resolves all of the concerns I know of.

IMHO, other simpler designs have fatal pitfalls, it's not worth pursuing.

I created a PR #27154 for the simple C-style approach as @mshabunin suggested. Since that PR competes with this one, I'd like to hear opinions from everyone.

In particular, I see that there are competing interests from primarily C++ users and primarily C users. C++ wants to use objects, shared pointers, STL containers, and mutexes, while C wants nothing of that. Personally I value correctness and safety above anything else, but I also understands that these values are already shared by both C++ and C users - they ask for idiomatic designs in their language of use, because of code safety concerns.

We probably need some battle-hardened developers who have seen things that we haven't. Particular of interest are: libraries that diamond-aggregate OpenCV (DeepStream?), any platforms not desktop Windows/Linux/Mac, mobile platforms, embedded platforms, novel architecture i.e. Loongson MIPS, risc-v etc.