cv::Mat parameter compile error

I keep getting the following compile error for this:

1
2
3
4
int size[3] = { 4000, 7000, 2 }; // 
	
cv::Mat LUT(3, size, CV_64FC1, cv::Scalar(0));

error underlined = 3, size

compiler complains:

'cv::Mat::Mat(cv::Mat &&)': cannot convert argument 2 from 'overloaded-function' to 'int

Ive tried changing the types for variables involved, other changes - I've even tried running it on a fresh copy. What am I doing wrong here?
Last edited on
get rid of the =

int blah[3] {1,2,3};
What happens if you change the name of the array? i.e. size replaced by, e.g. SIZE.

There is, after all, a new c++20 function called size().
jonnin: got rid of the blah

1
2
3

	cv::Mat LUT(3, 4000* 7000 * 2, CV_64FC1, cv::Scalar(0));



minus int size[3] = { 4000, 7000, 2 };

How are the 3 dimensions preserved?

lastchance:
1
2
int SIZE[3] = { 480, 752, 2 }; // row major
cv::Mat LUT(3, SIZE, CV_64FC1, cv::Scalar(0));


error compile
"typename not allowed"
Last edited on
Think of another name for the array - something not already used by some other variable or function that is in scope.

Which particular prototype of cv::MAT constructor are you trying to match? There are many.
Last edited on
cv::Mat LUT(3, (480, 752, 2), CV_64FC1, cv::Scalar(0));

??
So by:

eliminating this: int SIZE[3] = { 480, 752, 2 };

then keep & change:
 
cv::Mat LUT(3, (480, 752, 2), CV_64FC1, cv::Scalar(0));

this code is now accepted but a new error pops up:

error: subscript requires array or pointer type:
 
LUT.at<cv::Vec3f>(2, 100)[0] = 14000;

also left of '.at' must have class/struct/union
Last edited on
@technologist,
Why don't you provide sufficient code for people to actually see what is going on and what other variables are in scope?

I asked you earlier:
Which particular cv::Mat constructor are you trying to match?

There are many: https://docs.opencv.org/4.x/d3/d63/classcv_1_1Mat.html
Please respond.
Last edited on
Ok, so that's true but its because I didn't know which one to match. I somehow muddled my way through it. Thanks for the link.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
	//create mat
			//int xyz[3] = { 4800, 752, 2 }; 
	
		cv::Mat LUT(3, (4800, 7000, 2), CV_64FC1, cv::Scalar(0));

		//write to mat

		std::cout << "create the mat" << std::endl;

		for (int i = 0; i < 4800; i++)
		{
			for (int j = 0; j < 7000; j++)
			{
				for (int k = 0; k < 1; k++)
				
				{
					float random_1 = rand() % 100;
					float random_2 = rand() % 100;


					LUT.at<cv::Vec3f(i, j)[0] = random_1;
					LUT.at<cv::Vec3f>(i, j)[1] = random_2;

				}
			}
		}
		// sample:
		LUT.at<cv::Vec3f>(2, 100)[0] = 14000;
		LUT.at<cv::Vec3f>(2, 100)[1] = 19000;

		std::cout << "Access" << std::endl;
		cout << "Input mat x and y coordinates  : ";
		float x_in = 0;
		float y_in = 0;

//ACCESS
		cin >> x_in;
		cin >> y_in;

		std::cout << "3D value at (" << x_in << "," << y_in << ") = " << (LUT.at<cv::Vec3f>(x_in, y_in)[0]) << "," << (LUT.at<cv::Vec3f>(x_in, y_in)[1]) << std::endl;



Last edited on
Well, your line
LUT.at<cv::Vec3f(i, j)[0] = random_1;
clearly has an error (missing a '>'). But, as I don't use OpenCV, I don't understand why you need template parameters here anyway.

You don't need the k loop, as you aren't using it.
Last edited on
That was fixed, and k loop removed. Problem same. Errors persist 2,22 and
1
2
3

					LUT.at<cv::Vec3f>(i, j)[0] = random_1;
					LUT.at<cv::Vec3f>(i, j)[1] = random_2;


lines 2, 22

1
2
3
                                      LUT.at<cv::Vec3f>(2, 100)[0] = 14000;
                                      LUT.at<cv::Vec3f>(2, 100)[1] = 19000;


lines 28,29

 left of '.at' must have class/struct/union 
 subscript requires array or pointer type	
Last edited on
Why do you need the <cv::Vec3f> ?

LUT has already been created. It doesn't need template parameters.
Given that it is OpenCV, is there a more appropriate method of matrix management you might be suggesting? Am I "barking up the wrong tree?".

I don't need templates if I don't need templates. Yes, how do I access if not by the .at().
From what I understand .at() is relatively slower than other approaches.

The other reason for using templated approach was a desire for higher safely. If this is not true?

<cv::Vec3f> -- what do you suggest?

How do you access LUT w/out template parameters above ?
Last edited on

I don't need templates if I don't need templates. Yes, how do I access if not by the .at().
From what I understand .at() is relatively slower than other approaches.

Lets be precise. .at of vectors is notably slower. .at() of some library container may or may not be slow, depending on what it actually does in there.

I don't know openCv, probably should, but I do not. I will leave that to someone with experience. But to me it feels wrong to have some heavy handed thing for a lookup. A lookup should be as close to pure as possible ... an index into memory to fetch a value. Additional junk on top of that is unlikely to speed it up, and rather likely to slow it down. Neither has to be true, but generally speaking, using a fat matrix object that is designed for something completely different is a round peg square hole thing, and your odds of that being ideal are slim. If it does not have to be ideal, that is ok .. code reuse is a thing. I reused a matrix lib to do image processing, which was a sideways shove in and paint over it job ... it worked, and it saved dev time, but it wasn't really the best way to do it. Stuff happens :)
Last edited on
Honestly I feel this way as well. I just want the fastest retrieval possible of LUT values. The lookup will happen in real time while the the LUT creation will be at whatever time it takes to finish. When you were talking about the heavy handedness being for the lookup what alternative, if any, did you have in mind and can you point me there?
Last edited on
I already did, a 1 dimensional table of data with some sort of accessor (equation, pointer magic, whatever) to get at the value you want. A constant sized vector if a C pointer bothers you.

Edit, sorry, that was the other thread.
but the above still stands.
Last edited on
Topic archived. No new replies allowed.