Announcement

Collapse
No announcement yet.

OpenCV 4.7 Brings Numerous Improvements To This Open-Source Computer Vision Library

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OpenCV 4.7 Brings Numerous Improvements To This Open-Source Computer Vision Library

    Phoronix: OpenCV 4.7 Brings Numerous Improvements To This Open-Source Computer Vision Library

    OpenCV 4.7 was released today as the newest version of this widely-used, open-source computer vision library...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    ... OpenCV library for computer vision that was originally started by Intel ...
    Huh. I didn't know that.

    According to the wikipedia page:

    "... The main contributors to the project included a number of optimization experts in Intel Russia, as well as Intel's Performance Library Team. ..."

    I find this pretty shocking, because it always seemed to me that OpenCV was written by someone who did not have good handle on performance. The primitive operations tend to be image-level and the native color image formats are interleaved. Both are pretty dumb, from a performance perspective.

    That's not to say some of the routines in it aren't well-optimized, but if you're chaining together simple operations, you can often do better by taking care to stay in L1 cache. Also, when I've dug into some of the primitive operations, I've found significant room for further improvement.

    I generally regard it it as a reasonably efficient, easy way to do a first cut of some image processing pipeline in C++ or Python.

    Comment


    • #3
      Originally posted by coder View Post
      Huh. I didn't know that.

      According to the wikipedia page:

      "... The main contributors to the project included a number of optimization experts in Intel Russia, as well as Intel's Performance Library Team. ..."

      I find this pretty shocking, because it always seemed to me that OpenCV was written by someone who did not have good handle on performance. The primitive operations tend to be image-level and the native color image formats are interleaved. Both are pretty dumb, from a performance perspective.

      That's not to say some of the routines in it aren't well-optimized, but if you're chaining together simple operations, you can often do better by taking care to stay in L1 cache. Also, when I've dug into some of the primitive operations, I've found significant room for further improvement.

      I generally regard it it as a reasonably efficient, easy way to do a first cut of some image processing pipeline in C++ or Python.
      I'm assuming it's probably a legacy thing like the official story for why you have to convert your pixel format to BGR when loading things (TL;DR: When they created OpenCV, avoiding byte-swaps when feeding pixels into Windows GDI APIs was considered paramount for performance reasons).

      ...so my first questions would be:
      1. Were those Intel contributors around the last time they bumped the major version number and broke ABI?
      2. Are those Intel contributors in a position to be able to call for such changes to the ABI when a major version number gets bumped? (eg. Maybe the project leads don't feel comfortable maintaining what they propose. Maybe the project leads consider it an unacceptable API break for downstream users. etc.)

      Comment


      • #4
        Originally posted by coder View Post
        Huh. I didn't know that.

        According to the wikipedia page:

        "... The main contributors to the project included a number of optimization experts in Intel Russia, as well as Intel's Performance Library Team. ..."

        I find this pretty shocking, because it always seemed to me that OpenCV was written by someone who did not have good handle on performance. The primitive operations tend to be image-level and the native color image formats are interleaved. Both are pretty dumb, from a performance perspective.
        To what should image operations apply, if not image level? You can apply most operations on a ROI, if you want. If you want to operate streams, GAPI can provide some improvements, as it removes some setup costs if input and output formats are fixed.

        Native color format is not interleaved, interleaved is just one supported arrangement of data. Doing image operations on multiple planes is trivial in openCV.

        OpenCV is meant to be generic. Algorithms tend to be more than trivial image operations, and being able to speed up a single trivial operation by a hypothetical factor of two does not matter if this operation just makes up 1% of the total computation.

        Comment


        • #5
          Originally posted by StefanBruens View Post
          To what should image operations apply, if not image level? You can apply most operations on a ROI, if you want. If you want to operate streams, GAPI can provide some improvements, as it removes some setup costs if input and output formats are fixed.
          If you want good cache performance, then (depending on resolution) it's bad for each operation to process an entire image in a single pass. What you'd rather do is essentially create a small pipeline that operates on a chunk of the image at a time (i.e. assuming no stages require global data access). That should also scale well to multiple threads (i.e. with each thread operating on a different chunk) and accelerators like GPUs.

          Originally posted by StefanBruens View Post
          Native color format is not interleaved, interleaved is just one supported arrangement of data. Doing image operations on multiple planes is trivial in openCV.
          From what I've seen, and I don't claim to be an OpenCV guru, a lot of it seems oriented towards doing operations on interleaved data. If you want to use a planar representation, I think you have to go out of your way and process each plane as a single image, which is more cumbersome and therefore people don't tend to do it.

          Originally posted by StefanBruens View Post
          OpenCV is meant to be generic.
          That's what I'm saying. It seems to prioritize ease of use over performance. I'm not saying it's impossible to get good performance out of OpenCV, just that it's not designed towards the most efficient approach.

          Originally posted by StefanBruens View Post
          Algorithms tend to be more than trivial image operations, and being able to speed up a single trivial operation by a hypothetical factor of two does not matter if this operation just makes up 1% of the total computation.
          Some are; others aren't. It's not good to be dismissive about these things, because one is often not processing only a single stream of video, and doing lots of trivial operations quickly adds up. Given that it's ~20 years old, it was designed in an era when these operations were more costly.​

          Also, two decades ago, memory bandwidth was a lot lower and CPU caches were a lot smaller. And that brings us back to a key point I think passed you by. I'll grant you that pixel packing/unpacking is fairly cheap (don't underestimate it!), but memory bandwidth & cache space is always at a premium. Caches have gotten bigger, but so have images. And CPUs now have more cores contending for that precious cache space. Like the OpenCV authors, you ignore these concerns at your peril.

          Comment


          • #6
            Originally posted by ssokolow View Post
            When they created OpenCV, avoiding byte-swaps when feeding pixels into Windows GDI APIs was considered paramount for performance reasons).
            It's dumb to design your entire library around that. Just do a conversion when needed, like at the beginning and/or end of your pipeline. It beats the heck out of unpacking & re-packing pixels for nearly every operation in your pipeline!

            Comment


            • #7
              Originally posted by coder View Post
              It's dumb to design your entire library around that. Just do a conversion when needed, like at the beginning and/or end of your pipeline. It beats the heck out of unpacking & re-packing pixels for nearly every operation in your pipeline!
              Isn't that what they do? Expect the user to manually invoke an RGB-to-BGR conversion on data from RGB-format image files at the point in the pipeline which is best for performance or, if unsure, at the beginning?

              Comment


              • #8
                I really don't care about any of this as much as I wish they'd write some real, comprehensive documentation (look no further than numpy or https://scikit-image.org/docs/stable...mentation.html) and fix the bugs that lurk in their various CV paper implementations. I haven't found a single implemented algorithm yet that didn't have serious bugs or shortcomings. Even some better bindings for python that don't break in mysterious ways if you use the wrong kind of int would be welcome.

                These days I avoid openCV like the plague and use scipy or scikit image wherever possible.

                Comment

                Working...
                X