Random access on 3-channel, 64-bit, integer image?
Hello,
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.
Which version of opencv are you using? It works just fine for me, in release and debug, with 3.1.0
I am also using 3.1.0. So far, I've only tried this in Debug mode. This is really strange.
Are your yy and xx going out of bounds?
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.
Thanks.