避免进一步的解码器使用 opencv 仅加载 .png 数据

发布于 2025-01-10 19:43:16 字数 2575 浏览 0 评论 0原文

我试图避免搜索、加载或实例化除 png-Decoder 当使用 opencv 的 cv::imread 或类似的功能来获取来自 .png 文件的 cv::Mat。

但是， cv::imread 和 cv::imdecode 两者都执行加载其他几个解码器。因此，我查找了实例化的 Decoder-class 来解码 png-data，并尝试在我自己的 png-loader 函数中实例化和使用它。由于类 PngDecoder 用户无法访问原始功能所使用的代码。

处理图像的代码依赖于opencv。我考虑过 libpng 左右，但如果可能的话，我想坚持使用 opencv 功能。

不幸的是，现在我可以自己编译 opencv，因此编译器标志目前不适合我。

现在我想知道你们是否知道：

有没有办法告诉 cv::imread 或 cv::imdecode 在运行时加载哪些解码器？
有什么方法可以访问我尚未找到的特定解码器类吗？
是否有任何已知的原因导致这些类首先对用户隐藏？

提前致谢

更新： 为了避免进一步的误解，我想解释一下我希望避免加载不必要的解码器的原因：

我使用 gcc 的线程清理程序编译了我的项目，它通知我锁顺序反转导致可能的死锁，这与一些运行时观察相匹配我做的。 Stacktrace 和一些确定负责代码的代码缩减表明，cv::imread 调用，或更具体地说是 OpenCV 代码中 gdal 库内互斥锁的锁定，是造成这种情况的原因：

WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=174547)
  Cycle in lock order graph: M456973885219073664 (0x000000000000) => M458095095759505664 (0x000000000000) => M456973885219073664

  Mutex M458095095759505664 acquired here while holding mutex M456973885219073664 in main thread:
    #0 pthread_mutex_lock ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x4db3a)
    #1 CPLAcquireMutex <null> (libgdal.so.28+0x1074086)

我进一步研究了这种情况如何发生或如何避免这种情况。事实证明，每次 cv::imread 调用时都会加载 gdal dependent 解码器。这让我想到了我原来的问题：如何在使用 OpenCV 加载/解码图像时避免加载不必要的解码器？

原文

I am trying to avoid searching, loading or instantiating any other decoders than the png-Decoder when an image is loaded using opencv's cv::imread or similar functionalities to get a cv::Mat from a .png-file.

However, cv::imread and cv::imdecode do both load several other decoders. Thus I looked up what Decoder-class was instantiated to decode png-data and tried to instantiate and use it in my own png-loader function. This was not successful since the class PngDecoder utilized by the original functions is not accessible from user code.

The code processing the images depends on opencv. I thought about libpng or so, but I wanted to stick to opencv functionalities if possible.

Unfortunately, there is now way for me to compile opencv myself so compiler-flags aren't an option for me at the moment.

Now I was wondering whether any of you guys does know:

Is there a way to tell cv::imread or cv::imdecode which decoders to load during runtime?
Is there any way to access the specific decoder classes that I didn't found, yet?
Is there any known reasons why those classes are hidden from the users in the first place?

Thanks in advance

UPDATE:
To avoid further misunderstandings I want to explain the reason for my wish to avoid unnecessary decoders to be loaded:

I compiled my project with gcc's thread sanitizer which informed me about a lock-order-inversion causing a possible deadlock, which matches to some runtime observations I made. The Stacktrace and some code-reduction to determine the responsible code suggested that a cv::imread-call, or more specific a lock of a mutex inside gdal-library within OpenCV code, was the reason for this:

WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=174547)
  Cycle in lock order graph: M456973885219073664 (0x000000000000) => M458095095759505664 (0x000000000000) => M456973885219073664

  Mutex M458095095759505664 acquired here while holding mutex M456973885219073664 in main thread:
    #0 pthread_mutex_lock ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x4db3a)
    #1 CPLAcquireMutex <null> (libgdal.so.28+0x1074086)

I further investigated how this could happen or how to avoid this. It turned out that on every cv::imread-call gdal dependend decoders were loaded. This brought me to my original question here: How to avoid the loading of unnecessary decoders while loading/decoding images using OpenCV?

分享到QQ

分享到微博