in my case an encoded buffer may be a photographic or a medical image. i want to determine which image it is efficiently so that i can skip a photographic buffer if i'm expecting a medical image. thanks for the link - the changes there should address my need.

Is there an OpenCV function that allows us to do an initial check whether a given data buffer can be decoded by cv::imdecode() without fully decoding it?

Looking through the source for imdecode(), I do see that it utilizes a helper function findDecoder() to identify the correct decoder, but that helper is a static function. I'm wondering if there is public version of this function to do a quick initial check.

If there is no such public function, I should be able to write one utilizing the cv::ImageCodecInitializer container and following the code of findDecoder(), correct?

I'm trying to read a 16-bit signed TIFF image in OpenCV as

img = cv2.imread('000007.tif', flags=cv2.IMREAD_UNCHANGED)

but getting uint16 as the type of img. I looked at individual pixel values, but cannot figure out how OpenCV mapped the original pixel values (some of which are negative) to uint16 values. Adding additional flags cv2.IMREAD_ANYDEPTH and cv2.IMREAD_ANYCOLOR did not help. Can OpenCV read this image at all?

Hi all,

It seems from looking at the OpenCV source that the function cv::imdecode() creates a temporary file under some circumstances and decodes that file to create the decoded Mat object. Does anyone know under what conditions a temporary file is created? I see from code that the condition is !decoder->setSource(buf), but don't really know what that means.

Is there a way to avoid temporary file creation if all I have is a buffer to decode?

Thanks

I also tried to save in JPEG 2000 format using imwrite(string("water.jp2"), readMat), and got a blank file as result. JPEG 2000 is supposed to support alpha channel, correct?

Hi all,

It seems that OpenCV cannot write JPEG images with alpha channel. For example, the code

Mat readMat = imread("water.png", IMREAD_UNCHANGED);
imwrite(string("water.jpg"), readMat);

using water.png, a 4-channel image downloaded from here with white background, produces a jpg image with 3 channels and black background. Is this a bug in OpenCV, or expected behavior?

Thanks.

Hi all,

It was my understanding from previous posts (e.g., here) that algorithms that are potentially patented were included in nonfree module (till OpenCV 3.0) or a separate opencv_contrib repo (starting OpenCV 3.0). However, I just found out that the Haar cascade algorithm for face detection included in the objdetect module in OpenCV 3.0 is patented. So, a couple of questions:

1. Is Haar cascade object detection the only algorithm remaining in the main repo in OpenCV 3.0 that has patent issues? Or, do users need to check every algorithm in OpenCV 3.0 main repo for potential patent infringement?

2. I see here that one may still use the face detection feature in OpenCV 3.0 without patent infringement. Is this accurate?

Thanks!

Hi all,

I know there has been a post about OpenCV's issue with writing jp2 images with 16 bit depth, but I'm posting this here in case there has been a workaround since the last post. All I did was to read a 16-bit png image and write it back in jp2 format. Here's the code:

Mat readMat = imread("pnggrad16rgb.png", IMREAD_UNCHANGED);
imwrite(string("pnggrad16rgb.jp2"), readMat);

The image pnggrad16rgb.png was downloaded from here:

http://www.fnordware.com/superpng/sam...

The resulting pnggrad16rgb.jp2 image is just a completely black image of the same size as the original image (I viewed it in Gimp 2.8).

Has there been a workaround to this issue?

Thanks, Fijoy

I experienced a similar issue today. I read a 16-bit png file, and tried to save that file in jp2 format, without success. The saved image completely different from the read image.

So, let's say I read an image file into a variable buf of type char* using fread(), create a Mat object M by calling Mat(L, 1, CV_8UC1, buf) where L is the #bytes I read from file, and invoke imdecode(M, IMREAD_UNCHANGED). If the image I read is of depth 16 bit and has 3 channels, will imdecode() return a Mat object of type CV_16UC3?

Hi all,

OpenCV documentation specifies that I can invoke imdecode() with the same flags that we use in imread(). However, I am required to pass a Mat object to imdecode(), and this Mat object has a specific type. So, if I invoke imdecode() with IMREAD_UNCHANGED flag, will it reallocate the Mat object to have the same bit depth and number of channels as the input buffer? Or, will it ignore the IMREAD_UNCHANGED flag and convert the data to have the same type as the Mat object?

Thanks, Fijoy

Hi all,

I am in the process of integrating OpenCV into a large code base (100K+ lines). To track and control memory usage, I'd like to override all memory allocation and deallocations by OpenCV. I understand that I can override the new [] operator to partly achieve this goal.

However, OpenCV source also relies on malloc() calls. My research shows me that the easiest way to override malloc() calls is to use pre-processor macros like the one below since there is no portable way of overriding malloc (e.g., malloc hooks only work in Linux).

define malloc(X) my_malloc((X))

However, the macro option obviously will not work for pre-compiled binaries. My question is this: does OpenCV use any pre-built binaries that may be calling malloc()?

Thank you, Fijoy

I am trying to integrate OpenCV into a large codebase (order of 100K lines) that I have. To do this ideally, I would like to create C wrappers to the OpenCV C++ interface, since the C interface to OpenCV is deprecated. Does anyone here have experience in doing this? I understand that C wrappers to C++ libraries can be created using extern "C" in general, but I am looking for experience, potential problems, etc. specifically related to OpenCV.

Any resources, tips, experience, caveats, etc. you can share will help. Thanks much!

no, not an option to rewrite c code. it's in the order of 100K lines.

I'm trying to integrate OpenCV with existing C code, so looking into the C interface. I'm considering wrapping the C++ interface of OpenCV into C code, but don't know yet if that will be feasible.

Can anyone explain how exactly the refcount attribute is used in OpenCV structs? I am specifically looking at refcount in CvMat. I expected refcount to be used memory management, but looking at the source code (array.cpp and matrix.cpp), I see that the value of refcount is 0 or 1. I expected to see refcount incremented in shallow copy operations like cvMatToMat(const CvMat* m, bool copyData) with copyData=false. Am I missing something or not looking at the right source files?

Thanks.

The main issue now is that OpenCV 3.1 would prefer Python2.7 and Numpy 1.5 or later. We’ve not been able to locate an existing RPM for either for RHEL 6.7. Red Hat does provide a Developer’s Toolkit that we could install on RHEL 6.7 that would provide some newer versions of tools; however, it doesn’t provide everything required for the build (It does provide Python 2.7, but not Numpy 1.5). The main question now is whether we can build OpenCV with Python and Numpy.

Hey all,

I need to build OpenCV 3.1 on an older Linux machine, specifically Red Hat Enterprise Linux 6.7 (RHEL 6.7). Is this possible? I will need the C interface of OpenCV only (no Python).

If this build is not possible, what's the latest OpenCV version that can be built on RHEL 6.7?

Thank you, Fijoy

Hey all,

Does OpenCV implement any encryption algorithms? I understand that OpenCV can be used to implement, for example, image encryption, but I want to know if OpenCV provides any image encryption as part of its official release.

Thanks, Fijoy