Random access on 3-channel, 64-bit, integer image?

asked 2016-03-08 16:44:13 -0600

Nate gravatar image


For a project I'm working on, we need to use a 3-channel, 64-bit, integer image. Since there is no 64-bit integer image type available to us in OpenCV, we build the image with type CV_64FC3 and then just fill it by accessing its locations by pointer. That is, the cv::Mat object thinks it is a double-precision type but we filled in integer data in a bitwise manner. This part seems to work.

What does not work is getting information out of this image in a random-access manner using OpenCV's built-in .at<...>(...) function. I'd like to be able to access a part of the image as a cv::Vec<...> type, without having to use reinterpret_cast< uint64_t>(...) constantly.

Here's the code demonstrating the point:

// Works.
cv::Vec3d vd = img.at< cv::Vec3d>( yy, xx );

// Works.
cv::Vec< double, 3> vd2 = img.at < cv::Vec< double, 3> >( yy, xx );

// Fails with OpenCV assertion failure.
cv::Vec< uint64_t, 3> vi = img.at< cv::Vec< uint64_t, 3> >( yy, xx );

The assertion failure I get with the last line is:

OpenCV Error: Assertion failed (((((sizeof(size_t)<<28)|0x8442211) >> ((DataType<_Tp>::depth) & ((1 << 3) - 1))*4) & 15) == elemSize1()) in cv::Mat::at, file c:\path\to\opencv_301\include\opencv2\core\mat.inl.hpp, line 930

If anyone has any input as to what I am doing wrong, I would love to hear it. I'd really like to do the random-access here using the .at<...>(...) function as illustrated in the failing line above.

Thank you for your time.

edit retag flag offensive close merge delete


Which version of opencv are you using? It works just fine for me, in release and debug, with 3.1.0

Tetragramm gravatar imageTetragramm ( 2016-03-08 16:57:25 -0600 )edit

I am also using 3.1.0. So far, I've only tried this in Debug mode. This is really strange.

Nate gravatar imageNate ( 2016-03-08 17:10:52 -0600 )edit

Are your yy and xx going out of bounds?

Tetragramm gravatar imageTetragramm ( 2016-03-08 17:40:59 -0600 )edit
  • it is indeed a type problem.
  • the assertion is a DebugAssert, so you won't get one in release mode (which does not mean, there's no problem)
  • so, you found out, that uint64 is not supported. seriously, why put it into a cv::Mat then ? you cannot expect, that any further operation on this works as expected. (i.e, just try to add() 2 of them, you'll get funny results)
berak gravatar imageberak ( 2016-03-09 01:05:29 -0600 )edit

You are absolutely correct that the built-in OpenCV functions would not work on a cv::Mat filled with uint64s. I was just hoping to be able to use the container infrastructure to do the memory management. All I really wanted from this exercise was a reliable way to store and retrieve values. Looks like I should probably go ahead and write my own container instead.


Nate gravatar imageNate ( 2016-03-09 10:26:20 -0600 )edit