ClintFromVa's profile - activity

Sorry for the long absence, busy weekend. Anyway, for testing you could just add a raw delay at the top of your loop...something like waitkey(1000); Play with the number and see if there is a threshold which works, it would be cool to know just how fast the camera refreshes.

A better answer would be to check the size of the returned image and just try again when image.empty (or image.rows == 0 && image.cols == 0 ) is true.

Good luck!

OK, I zoomed in on your screen grab enough to read the actual error message...it is saying that when imshow ran, it had an input that was size 0x0.

My best guess is that the camera is slower than your code and sometimes the capture fails, producing an empty image. I would put in a test for empty, just like when you use imread on a file.

OK, I've got to be going crazy here.

I ran one of the tutorials for affine transformations (I am actually starting to care about image coordinates).

I am using an image that I KNOW is 980 rows x 586 columns (checked it in paint).

   /// Load the image
   source = imread( argv[1], 1 );

   /// Set the dst image the same type and size as source
   warp_dst = Mat::zeros( source.rows, source.cols, source.type() );

then I get this in the watch window:

source.rows and source.cols are swapped, what is going on?

Your roi is a single row... is that what you intend? Just a guess, but that single dimensionality may confuse the following imshow.

I ended up scanning the contours point by point and multiplying each by the rotation matrix. Maybe there is some sort of typecast that operates on a vector and would have let me use perspectiveTransform, but I've no clue what it may be.

Hi all,

I've got a contour for a flat, irregular shape with ~ten, 2D, points. I'd like to project just that contour, not the whole image, into a normal view and then find area, etc.

I know the contour is OK because drawContours has the expected result. The rotation matrix, Rot3D, works with warpPerspective on the full image (I play with the rotations for the background in a calibration step, then try to use the same rotation matrix here. It is a (3, 3, CV_32FC1) ).

I simplified everything to this code: `

////this builds a contour-like structure for testing...
vector<Point2f> foo = { { 0, 0 }, { 0, 1 }, { 1, 1 }, { 1, 0 } };
vector<vector<Point2f>> bar;
bar = { foo, foo};
//which ought to work with this...
contours1.resize(bar.size());
for (int i = 0; i < bar.size(); i++) //for each vector of points in the list...
    perspectiveTransform(bar[i], contours1[i], Rot3D);//rotate them.

` which fails an assertion check:

No clue what that means...contours1 is a vector<vector<point>> ... Douh! could that be it...

OK, findContours produces <point> (i.e., two int), perspectiveTransform requires <point2f>

OK, pulled out phasePart, but it is still just snow (see above). I am thinking of doing a polar histogram on just magnitude of one quadrant, the biggest pile will be in the direction I care about (maybe).

So now the OP has a DFT that works (as I do), how do you find the angle from the result?

@matman, Thanks for the attention to this.

EDIT - problem was, I redefined "src" in main so the global variable used in other functions was still blank (hangs head in newbie shame).

I'm deleting the rest of this...

Thanks.

Trying to post code...too long for comment window.
Putting it below.

The DFT tutorial ends with

...the most influential components of the frequency domain (brightest dots on the magnitude image) follow the geometric rotation of objects on the image. From this we may calculate the offset and perform an image rotation to correct eventual miss alignments.

Tantalizing. How? My result:

has features at about 45 and 135 degrees as expected so the DFT part worked. Is there something I can extract directly from the complex values of the DFT result?

And close the duplicate question.

Well, the Assertion is saying that the number of channels is wrong. Best guess is that you still have color when you need to go either grey (or extract one of the BGR components). I thought the imread should have handled that but the flag to convert to grey is not explicit. Try src = imread("Filename", 0); //0 for grey, 1 for color.

The step you reference (line numbers please!) is where the complex dimension gets added to the image data. It looks like you copied the tutorial verbatim. Is padded bigger than I at this point as it should be?

Otherwise, I'm just trying to read through the tutorial. It looks like you copied that anyway, why not run that with your image? Then let me know how you get the angle!

EDIT

I think the spirit of the original question was how to interpret results like these:

EDIT Pulling out phase as suggested. Similar quadrant swap but not log scale of course.

OK, I'm working on a cleaned up version to isolate the problem.

When I said 1/3 of the image I meant the top 1/3 with the remaining pixels being unchanged. And that number was approximate anyway.

I was trying to set this up so I could use a trackbar to set the threshold. I just copied a tutorial example and dropped in a different function. The examples use global variables liberally (bad form but hey, it is a tutorial). In this case, inside the function the data Mat was blank. That makes sense with the assert that threw the error but I don't know how the global variable didn't work.

This has moved far away from where I started - what is good form here for this question? Retag it? Close it and ask again better?

For only a single channel, you could use this:

Mat src_grn = Mat::zeros(src.rows, src.cols, CV_8UC1); //green channel from src
int from_to[] = { 1, 0 }; //copy green channel only (assume BGR)
mixChannels(&src, 1, &src_grn, 1, from_to, 1);

I'm grabbing the green only from a white-hot object, which has the best contrast. Dimmer things will need some other tricks though...let me know how it goes!

No, neither mode works. Release mode, invoked from the command line, fails with a windows 'program has stopped working' popup and the quoted text on the command line, '... line 266.' Debug mode pops up the 'unhandled exception' window, indicates the imshow is the next to execute, and opens a second console window. This second window today matches the release mode one, blaming an assert in window.cpp line 266, yesterday was different (screenshot above). I rebooted the PC and cleaned the project prior to this, no other changes.

I just checked, I'm definitely using the 'd' version libraries in debug mode.

Off to try a demo straight from the documentation...

This is a weird one.

adaptiveThreshold(src_grn, scratch, max_BINARY_value, ADAPTIVE_THRESH_GAUSSIAN_C, THRESH_BINARY, 3, weight); imshow(output_window_name2, scratch);

gives 'unhandled exception' in debug mode, with the second line being indicated as the next to execute after the break. In release mode, the command line shows:

OpenCV Error: Assertion failed (size.width>0 && size.height>0) in cv::imshow, fi le C:\builds\master_PackSlave-win64-vc12-shared\opencv\modules\highgui\src\windo w.cpp, line 266

with the same input file.

src_grn is an image of CV_8UC1 type (green channel extracted from an RGB image with mixChannels earlier). Mat scratch is declared earlier but not initialized to any particular size or type.

If I continue instead of breaking after the exception it looks like the top 1/3 of the image gets filtered. Commenting out the imshow prevents the error (not that that is helpful).

Putting the imshow back in and setting the window to autosize spits out:

(sorry for the screen grab, it won't let me copy the text) something about 'Bad flag' in core\src\array.cpp, line 2489.

Commenting the adaptiveThreshold line gives my source image back again, displayed normally.

This is OpenCV3.0 under VS13 express.

Ideas?

Hi all,

I installed CV2, got some demos working, then decided to try CV3 when I found an interesting one that depended on it. CV3 installed and the new demo works but now (HA!) the old ones are broke. I gather there are significant changes in the API and a lot of legacy support is gone. Does anyone have a list of what is gone and what replaces it? Other things I should know for a successful migration?

In case there is no better answer, I know O'Reilly has a second edition of their OpenCV book for 3.0 coming out end of April. Hopefully that will highlight changes but I don't want to wait.

For what it matters, I'm working in C++ under VS13.

Thanks

Update: an example of the gotchas I've found. imwrite, according to this 3.0.0 API ref, supports a number of parameters including CV_IMWRITE_JPEG_QUALITY. The 'CV_' prefix kills it...apparently points back to an obsolete C header, imgcodecs_c.h. Point is, removing 'CV_' is proper (works anyway) for CV3. The example code farther down has the same problem.

What makes it hard to find is that the enumeration exists, just isn't #INCLUDEed ... because it shouldn't be. It would be better if the deprecated header didn't exist. I installed from the .zip file so I don't think I grabbed stuff I shouldn't have.

I did check the references in the answers (thanks again), but didn't see/understand if there a list of these kinds of things, should there be?

Big fight with this today. Instructions for VS13 install work for CV2 but are misleading for CV3. Bottom line, you need to tell the linker about the contents of $(OPENCV_DIR)\lib, which are only opencv_ts300d.lib;opencv_world300d.lib, not the long list it was before.

I've been working on something similar. For a target, I started with a surveyor's benchmark (2x2 checkerboard) but now think a 1x1 colored square centered in a 3x3 white one would work better.

What type of camera/sensor are you using?

Hi all,

I think I have this figured out but I'm interested in your perspective. I'm working in C++ under VS2013.

From the documentation on rotated rectangles there is this declaration:

    Mat image(200, 200, CV_8UC3, Scalar(0));

That looks like 200 x 200 pixels, 8-bit BRG color, with three color values passed in by the Scalar (Scalar being anything other than a simple number is a confusing offense unto Nuggin but is discussed elsewhere).

I wanted to check if the type casting really worked, storing 24 bits per pixel, or if the Scalar was still reserving four doubles for each. Finding (int)abs(image.datastart - image.dataend) resulted in 3 unsigned char per pixel ... which Microsoft says is a 1 byte type (MS VBA is 2 bytes for a char, go figure). So that all looks as expected, minimum space used and all is well.

Problem though, I think I read as I researched this that under some matrix arithmetic operations the data gets changed to type float. I guess I could see the utility in that but it seems like a gotcha too. Does that really happen? What is good practice here?

Thanks