Ralph058's profile - activity

I have used a couple of CV_32FC3 for processing and wish to convert one of the channels of each into CV_8UC1. I tried this:

Mat imgMedR(157, 78, CV_16UC3) ;
Mat imgMedL(157, 78, CV_16UC3) ;

    Mat imgFiltR(157, 78, CV_32FC3) ;
Mat imgFiltL(157, 78, CV_32FC3) ;
medianBlur(imgLocsL, imgMedL, KernSize); //imgLocsL & imgLocsR work fine without the snippet shown
    Scharr(imgMedL,imgFiltL, CV_32F, 1,0);
medianBlur(imgLocsR, imgMedR, KernSize);
Scharr(imgMedR,imgFiltR, CV_32F, 1,0);

Mat imgL(157, 78, CV_32FC1);
Mat imgR(157, 78, CV_32FC1);
Mat imgBGR_R[3],imgBGR_L[3];
split(imgFiltR, imgBGR_R);
split(imgFiltL, imgBGR_L);
imgR = imgBGR_R[3] / 64.0f;
imgL = imgBGR_L[3] / 64.0f;  //Valgrind says I have a segment fault here but not the line above.

//the error identified is imgR.convertTo(imgRight, CV_8U); imgL.convertTo(imgLeft, CV_8U);

The Valgrind err messagesa re Conditional jump or move depends on uninitialised value(s) Use of uninitialised value of size 8 and Invalid read of size 4

I confused. If imgLocsL and imgLocsR are OK, then the variables in the Mat at the offending line should have a valid value of type CV_32F.

If the error was after the converto, then I could save the image and look at it.

Anybody have any hints on how to troubleshoot this?

Thanks Ralph

It looks like I answered rather than commented. Hence, it may not show up for a few days.

The first hint solved the problem. It appears that the sparseMat is populated in random order, so I can't use the iterator..

I am trying to access elements in a sparseMat using value and the iterator.. The elements are of the type Vec5f, which has been declared.

typedef Vec<float, 5> Vec5f;

The iterator is declared with

 cv::SparseMatConstIterator_<float> it = sparseLoc.begin<float>();
 cv::SparseMatConstIterator_<float> it_end = sparseLoc.end<float>();

The IDE (Eclipse) doesn't allow using type <vec5f> for this.

The loop is

for(; it != it_end; ++it)
     {
         float Iter = *it;
         const SparseMat::Node* itNode = it.node();
         Spot = it.value<Vec5f>();
         Intens = Spot[I];
         Vert = Spot[V];
         Horiz = Spot[H];
         DeltaH = Spot[DH];
         DeltaI = Spot[DI];
         itTestFile << Iter << ", " <<  Intens << ", " <<  Vert  << ", " << Horiz<< ", "
                         <<  DeltaH  << ", " << DeltaI << endl;
     }

(If you are trying to figure out its purpose, I am trying to see how the iterator and the x,y access compare.) I get the exception

OpenCV Error: Assertion failed (_m->type() == DataType<_Tp>::type) in SparseMatConstIterator_, file /usr/local/include/opencv2/core/mat.inl.hpp, line 2888
terminate called after throwing an instance of 'cv::Exception'
  what():  /usr/local/include/opencv2/core/mat.inl.hpp:2888: error: (-215) _m->type() == DataType<_Tp>::type in function SparseMatConstIterator

It doesn't show the calling line number. i tried changing the Vec5f in the it.value statement and I get the same exception. So, I assume it is thrown by the SparseMatConstInterator_ declaration.

Any hints on how to fix this?

Thanks Ralph

Thanks.

I think you are correct but I'm still getting a cast error. I'm working on it.

The indexes were correct for the target image because I am using it in the portrait mode. However, the camera system does not know this. In stead of 'clone', I will use 'transpose.'

I have a module which receives a void pointer to a buffer. The original data type is uint16.

When I try putting the variable into a Mat, I get weird errors from

Mat imBuff = cv::Mat(628, 314, frame, CV_16U);

like missing '}' which isn't missing.

When I try various conversions using reinterpret_cast, I get cast from 'void*' to 'xxx' loses precision. For example,

 Mat imBuff = cv::Mat(628, 314, reinterpret_cast<uint16_t >(frame), CV_16U);

 fives 'uint126_t' {aka short unsigned int}' loses precision

Any ideas on how to solve this?

Or, do I have to go back to the source file and change it there?

thanks Ralph

This is probably a C++ question but I can't find it there either. I have a sparseMat that I want to recast as a const sparseMat so I can use SparseMatConstIterator. The examples are all for this and --operator seems to not be available for SparseMatIterator.

Thanks. I understood 'prefix' and 'postfix', but I still don't understand the convention shown. Your comment should be helpful to those who dont.

For an iterator declared as 'it', if i wanted to use "prefix" iterator then, I would use "it.operator++(int)" ?

Both SparesMat::operator++() and SparesMat::operator++(int) have the same definition in the docs, namely "moves iterator to the next element". Since it is not defined as SparesMat::operator++(int step) (or some other variable), I am a little confused. Does it increment by the value placed in the parenthesises or is a "don't care"?

The description of sparseLoc.hash returns a value of type size_t. The description says it returns the hash value. My analog of the hash value is the index of the occupied cells. That is, if the three occupied cells (and array index) are 4, 8, & 12, then if I put in sparseLoc.hash(12), would it return 2 (0,1,2) or 3 (1,2,3)?

If this is 2 do I extract the value at that location with sparseLoc.value<float>(2)?

Thanks Ralph

std::iterator template <class category,="" class="" t,="" class="" distance="ptrdiff_t," class="" pointer="T*," class="" reference="T&amp;&gt;" struct="" iterator="" {="" typedef="" t="" value_type;="" typedef="" distance="" difference_type;="" typedef="" pointer="" pointer;="" typedef="" reference="" reference;="" typedef="" category="" iterator_category;="" };<="" p="">

I am using a sparseMat which contains points on a nominal pitch of 4 with respect to the index (for example: PIXEL1, NULL, NULL, NULL, PIXEL2) . I would like to extract a 3x3 matrix which contains the last three valid pixels of the current row and the rows before and after. The sparseMat (sparseLocs) is created by iterating over rows and then cols. Hence, the first element is -3 from the current iterator position. I think I can use something like sparseLocs.addref(-3) and I think I can find the row and col by something like sparseLocs.hash(row, col) for that pixel. I am not getting it from the documentation. Can someone point me to the right documentation to understand this? Thanks, Ralph

As near as I can figure out, a goto inside of an if statement is corrupting the write, somehow. Since the creation of an element in the sparseMat occurs after the if statement, it makes no sense. if (New_V == sparseLoc.ref< Vec5f >(y_R_idx/4 - 1, x_C/4)[V]) { y_R = y_R + 4; //recalculated maxLoc goto findLoc; } If the previous sparseMat's row's point at that same location is the same as the value just calculated, then it will add 4 rows and go back to the point where the center peak is found. by commenting out the goto and the label, it works fine. I will have to study goto a little more in depth to figure out what is going on.

I commented out the #ifdef and the whole #else and get the same results.

Hi I am writing and then reading a sparseMat using the process in the answer to this question: http://answers.opencv.org/question/80...

Up until a few days ago, this worked fine. I made no changes to the read/write code, but now, it isn't reading.

To help me isolate the problem, I added a read to the module doing the writing as:

endofconvert = write2d(LocFileName, sparseLocR);
endofconvert = read2d(LocFileName, sparseLocR);
cout << "size of read file = " << sparseLocR.nzcount() << endl;

The endofconvert is normally 0, unless there is a problem. I have not put a trap in the write2d or read2d yet. So, it returns 0.

The lines following parse sparseLocR and return a text file with each non-NULL element. These look fine with the read statement commented out. The written file (LocFileName) appears to be the same size that it always has been. Adding print statements (cout) inside gives me what I expect, for example:

s.write((char*)&i, sizeof(int));
s.write((char*)&j, sizeof(int));
s.write((char*)&e, sizeof(Vec5f));
cout << "row = " << e[V] << "    Col = " << e[H] << "    Intense = " << e[I] <<endl;
(V=1, H=2, I=0)

Adding the same print statement in a corresponding location in read2d gets no results, but if I move it outside of the associated #ifdef, it does. #ifdef SPARSEBINARY appears to be working for the read2d because I put a print statement in the first incidence of #ifdef and it works:

 #ifdef SPARSEBINARY
  s.read((char*)&h,sizeof(int));
  s.read((char*)&w,sizeof(int));
   cout << "Reading " << FileName << endl;

(and it works in the write2d. both functions share the same header, thus #define SPARSEBINARY) Searching on this doesn't do much good. I guess that I'm not asking the right questions.

Any suggestions on how to troubleshoot this or how to ask the right questions?

read2d appears to be working. For some reason, it doesn't like the read and write in the functions in the other project. So, I added a read2d line after my write2d line to read the file I just wrote. I put m.zncount() and got my expected 12164. This is out of 197192 pixels in the dense Mat. According to my calculations, I should get between 12007 and 12167. (Which is why I am using SparseMat.) The #includes all seem OK. The .cpp was copied and pasted from the project where it works. I assume it is some kind of linkage problem, but I don't see it. I assume the residual problem has nothing to do with OpenCV and my question has been answered. Thanks a lot.

Berak It could be a Windows 10, cut and past asynchronous innovation peculiar to my desktop. I am running the IDE in Ubuntu 12.04 in a VirtualBox. I use Code Composer Studio because of the TI targets in the system.

The write2d function seemed to work and produced a file of the size that I expected, which fits my bandwidth. Now, I have to fix the next module to use read2d. I use strings for file names. So, I added a conversion at the front of each function: int read2d(filename FileName, SparseMat &m) { const char *fn = FileName.c_str();

Just in case some one else has that problem, I passed this on. When I copied the code, CV_32FC(5) wasn't liked by the analyzer. I typed it in again and it worked. It appears that there was a hidden special character or a Unicode issue (some other character substituted for what appeared on the screen).

Thanks. It looks like it will work.

I looked at how OpenCV handled imread and imwrite. OpenCV 3.0 documentation says that it supports reading and writing EXR. However, the encoder in grfmt_exr.hpp is too simple to handle anything but RGB and I would have to write my one encoder, at least. I had come to the conclusion that rolling my own was the only answer. Since I am more of a hacker than a software engineering, I would have had to ask someone else to write it. I will give your take a try.

The attraction that I saw in using OpenEXR was using half float. Most image processing numerical analysis issues are with the dynamic range. 10 bits of mantissa are sufficient (actually 11 with the implied first bit from the exponent) with most image processing with most sensors.

You might want to consider that the green channel dominates an image. You may be able to have your color and your three times processing by just enhancing green. In fact, with most solid state imagers, the blue and red have 1/2 the resolution as the green channel. Edges are detected from the green pixels and added to the blue and red to fake the human eye into believing that there is an improvement in resolution.

You need to provide some more specifics. Does this have to be done in real time? How far in advance of the sign do you need it, etc. Even more important is what sign system are you trying to recognize, Is it US, European, Middle Eastern? Is left hand drive or right hand drive? As far as algorithms, etc, try searching. I found too many good papers to make a suggestion using: machine vision road sign recognition stop sign

Since understanding your specific needs is key to what constitutes the best algorithm, I would suggest you start with a review article such as http://ijarcce.com/upload/2015/july-1... paying particular attention to references.

Then, identify the environment, sensors, processor, etc. Then some one can provide what is best, but then again, you probably will have already discovered it.

For example, if you have the view of all lanes from the top, you have a simpler algorithm than if you have to view it from the side or lanes are obscured. Perhaps you could ask yourself if accuracy is what you want or is reliability and minimum costs.

The only way that I have found to write a SparseMat is with : void write( FileStorage& fs, const String& name, const SparseMat& value ) from persistence.cpp line 5493. This writes it as a YAML document and does not accept a path but only the file name. The desired SparseMat is two-dimensional with Vec5f data.

I think I can use OpenEXR organized with 5 channels as it supports arbitrary channels, but it is looking for a dense matrix and I want to reduce formatting and transmission time for what would otherwise be a very large matrix. This would probably involve a sparse to dense on the one end and a dense to sparse on the other.

Is there an example of writing a binary SparseMat out there?

Thanks Ralph

My analysis tool didn't like the way you had written the typedef. It is happy with : typedef Vec<float, 5> Vec5f; In response to your comment, I changed the if statement to: if (sparseLocL.ptr(y_R_idx,x_C_idx, false) != NULL){

It was happy with the usage of .ref as : NewLocValL_H = sparseLocL.ref< cv::Vec6f >(y_R_idx,x_C_idx)[H]; because that is the way it is in Kaehler & Bradski's Learning OpenCV3 and the analysis tool is happy.

I have some compile errors which having nothing to do with OpenCV. When I clear them and try to run it, I may make a change, but I consider it to be answered.

This is in static analysis with Eclipse. The compiler also recognizes the instantiation as being in error. Specifically, the line: if (sparseLocL.ptr< cv::Vec6f >(y_R_idx,x_C_idx, false) != NULL){ yields the following error: error: expected primary-expression before ‘>’ token I do not see an extraneous '>' and I don't see a problem with the previous line or two. This link uses the same syntax as my line: http://stackoverflow.com/questions/15...

It is happy with: NewLocValL_H = sparseLocL.ref< cv::Vec6f >(y_R_idx,x_C_idx)[H]; and that is immediately after the if statement.

I'm running Ubuntu 12.04 with gcc 4.7 native compile on an AMD-64 processor. The version of Eclipse that I am using is Luna modified to be TI's Code Composer Studio 6.1.

I declare sparsLocL as: SparseMat sparseLocL( 2, sparseSize, CV_32FC(6)); //only 5 are used

I tried declaring as: SparseMat *sparseLocL( 2, sparseSize, CV_32FC(6)); //only 5 are used and it made no difference.

Any ideas on where to look for the root cause?

Hi I can write but not read either an XML or YAML contour file. The contour is declared with: vector<point2i> sortedContour;

I write the file with:

FileStorage fs("SortedContour.xml", FileStorage::WRITE); fs << "sortedContour" << sortedContour; fs.release();

The file written is: %YAML:1.0 sortedContour: [ 37, 28, 38, 28, 39, 28, 41, 28, 42, 28, 46, 28, 31, 29, 35, 29, 36, 29, 40, 29, 43, 29, 44, 29, 45, 29, 47, 29, 31, 30, 32, ....MANY MORE ROWS OF NUMBERS..... 137, 57, 137, 58, 137, 59, 137, 48, 138, 49, 138, 51, 138, 55, 138, 56, 138, 50, 139, 52, 139, 53, 139, 54, 139 ]

FileStorage fsR("SortedContour.yml", FileStorage::READ); if (!fsR.isOpened()) { cout << "failed to open " << "sortedContour" << endl; return -1; }

fsR["SortedContour"]>>ContourR; fsR.release(); //int Rsize=0; int Rsize=ContourR.size();

if( Rsize==0) { std::cout << "Rsize: " << Lsize << '\n'; return -2; }

The (Rsize == 0) jumps out of the program as the variable is empty.

This is being done on a Ubuntu 14.04 Linux desktop using OpenCV 2.4.8.

The implementation of this program is being used in an embedded system. The written file is transferred to another processor where it is read.

I've been searching for sometime for a solution. If I come up with one, I will post the answer. Ralph

Why is the system writing four bytes when the number size is one byte?

How can I correct this fault?

While I have no idea what the problem was with

Yold = inContour[0].y;

by compiling it with the debug flag, it went away and it stayed away when I set the release flag.

Having said that, the line

sortedContour[0].x = inContour[0].x;

caused a segment fault because sortedContour had not been sized. I will allow that the Yout line was always OK and I was misinterpreting the condition. That would make more sense than a self healing program.

Adding the lines:

int sz2=inContour.size();

sortedContour.resize(sz2);

corrected the latter segment fault and the code executed properly.

stable_sort was verified by manually reading the YAML file.

I haven't figured out how to past code cleanly.

Declaration of vector of points vector<Point2i> inContour; vector<Point2i> sortedContour; vector<Point2i> prunedContour; NOTE: this was also done using Point, with the same results

The following is the code at issue: std::stable_sort (inContour.begin(), inContour.end(), compare_y); FileStorage fs("SortedContour.yml", FileStorage::WRITE); fs << "inContour" << inContour; fs.release(); std::cout << "inContour y: " << inContour[0].y << '\n';

Yold = inContour[0].y;

sortedContour[0].x = inContour[0].x;
sortedContour[0].y = inContour[0].y;

While it handles the cout OK, it generates a segment fault with the line Yold = inContour[0].y;

If I comment it out, then it generates one with the next line.

stable_sort works OK.

Hi I get a segmentation fault when I extract an element from a contour in a replace statement but not in cout.

The first line prints fine, but there is a segmentation fault with the second line.

std::cout << "inContour y: " << inContour[0].y << '\n';

Yold = inContour[0].y;

At the point in the above code, I have isolated the largest contour and sorted it by the y terms. All appears OK with the sorted contour.

Yold has been declared with int Yold;

and inContour has been declared as vector<point> inContour; several lines above this. Moving the declaration of Yold to this line did not help.

Point is supposed default as a 2 parameter integer. Specifically declaring it as Point2i did not help.

Any suggestions?

I have been having some problem with Mat based images not looking like I believe they should in CV_16U and CV_8U. I have found that CV_32S works OK, but I have no reason to transmit such a large image. In fact, one of the images could be a boolean but there seems to be no boolean format for Mat images. Also, I'm bandwidth limited. Four 157 x 105 Mat have to be transmitted over USB2.

The images in the other two integer formats do not have the same numbers I get using cout nor are continuous blocks continuous but rather striped with 1 to 3 spaces of 0. The index also is continuous in the printout.

More bazaar, if I output the image cell immediately after the replacement statement, I get the right number and no spaces.

rowSilh[spotCol] = 255; cout << "Col = " << spotCol<< endl; cout << "Silh = " << rowSilh[spotCol]<< endl;

The two couts have the right numbers but.

The display does not match and the file from cv::FileStorage silh("imgsilh.ext", cv::FileStorage::WRITE); silh << "imgSilh"<< imgSilh; silh.release();

However, the display and the file match.

If I process in 32S then convert to 16U or 8U as needed. Everything works OK. It appears the issue is to the method of writing to pixels.

For what it's worth, I'm on Ubuntu 14.04 and OpenCV 2.48.

I suspect a bug, but, if so, there should be someone else out there using the format.

It appears an issue with 16U. I converted the Mat to 16S. It seems to work fine.

I don't have time to diagnose what the issue was. I was outputting unsigned numbers less than 16bits. I had changed the rescale to 64 and then 32 and still had 65535 in the output even though the largest number I found in printing the values was around 41000. The middle of the row, where a couple of the 65535 occurred, should have been no more than 20000 with the 128 multiplier.

I should probably report a bug report, but I still don't know if it was something I was doing.

Ralph

Hi I run an algorithm that extracts points of light from an image. In Octave (an Open Source Matlab), I extract 7557 points and get an image that is about what I expect. In OpenCV, using line for line the same code in the executable, OpenCV gives 3196 and the image looks more like noise.

The only difference is the access of the pixels. In Octave, I use pix4=imgNIR(newRow, newCol). In OpenCV, I have tried pix4 = imgNIR.at<uchar>(newRow,newCol) and the equivalent extracting the row using rowNIR = imgNIR.ptr<uint>(newRow) and pix4 = (int)rowNIR(newCol).

As I need negative numbers in some intermediate results, I need 'int' or 'long' data type. (I've tried both.) In Octave, I use uint32.

I have been able to replicate the size issue in Octave to a degree. The 7557 becomes something around 4000.

I have tried imaging at various points with additional Mat files. The one place I need to, I get a segment fault. It appears that there are little or no exception handlers. I inadvertently tried to address outside of the rows. Rather than some kind of index size error, I get a segment fault. I've found a few other causes of segment faults, but they don't apply here.

In Octave, the resulting image is now continuous except where I either have a phase error in the dot position or the spots are too dark. In OpenCV, there are vertical bands every other column. The output image is supposed to be a ramp that contains the subpixel position information. If I were using floating point, it would be the column of the spot centroid plus a decimal. I convert it to integer by premultipying by a constant. I'm using 128, but anything greater than 16 would do. The result in Octave is a continuous ramp. In OpenCV, the values jump up and down across the image in no particular pattern.

I've used cout to print the row, col, and value int the row. Those results look OK. My best guess is that it has something to do with the replacement statement:

rowSpot[spotCol] =(unsigned long)testVar;

I'm using the pointer read writes. I'm getting similar results using .at:

imgSpots.at<long>(spotRow, spotCol)= testVar;

Although, with the latter, there seems to be two missing pixels in the banding rather than one with the pointer method.

Any suggestions or debug hints will be appreciated. Thanks Ralph