Image Threshold Produces Black Image

[DjScribbles]

We used the NI Vision Assistant to generate code, and the script there works great on all our images, however once we generate code, modify to compile, and deploy to the robot, it doesn't seem to work properly.

I added code to write the image out to the CRIO filesystem as a jpeg before and after the threshold, the image going in looks normal, and can be loaded in vision assistant and results in particles as we expected; and the image saved after the threshold is just black.


We have additional steps doing particle analysis, and some custom code that decomposes the particle analysis results structure (which could be the problem, haven't debugged heavily yet).

Is there a reason this image is all black, I saw several labview topics where it has to do with the color pallete in labview, but is it a similar issue i'm seeing when I ftp to the robot where the squares are just dark-grey (and throwing me a red herring), or is there something different in the threshold function that is a problem.

Here is some psuedo code of what we're doing:
1.get camera image as color image (write it out)
2.run HSV threshold filter,
3.storing the result to binary image (write out binary image, this one looks black),
4.apply other image processing steps, convex hull + particle filter + particle analysis (we pass back the particle analysis by reference)
5.decompose the particle analysis results searching for the result name "Center Of Mass X" (i think) using if(strcmp() == 0)


If anyones got some helpful info or ideas it would be appreciated, once I figure this out I'll post back what went wrong.
tldr; I'm mostly curios if the black image is ok (just a color space issue) or if the threshold operation is failing to find anything.

[bob.wolff68]

I can almost certainly help you here. Our team ran into what sounds identical this weekend. One question though - when you do GetNumberOfParticles() on the BinaryImage, do you get non-zero results? If so...

When you call BinaryImage's Write() function, instead of writing a .JPG file, write a .BMP file.... what? Yea... seems to be a bug to me. We were writing Write("thresh.jpg") and it was all black. At some point, I decided to make it write a bitmap instead and changed to Write("thresh.bmp") and it works perfectly...

bob

[DjScribbles]

Awesome thanks for the info.
I will try writing out a bmp later and hopefully see some more helpful results.

I'll have to take a closer look at the BinaryImage class too, I didn't look to much at it's interface because we're doing the bulk of processing in the generated C code, and only just added the HSV conversion in the calling code to try debugging this.

[bob.wolff68]

I must say that the C++ library is quite straight forward and seems to work quite well too.

AxisCamera::GetImage returns ColorImage* ... (or HSLImage* due to inheritance)
ColorImage::ThresholdHSL returns BinaryImage*
and BinaryImage:: has the particle analysis routines. Tada. Right down the line...very little babysitting other than making sure to delete the pointers given back to you or handle the GetImage differently by passing in your own ColorImage address.

bob

[Alan Anderson]

A binary image has pixel values of 0 and 1. That will display on a grayscale indicator as black and just slightly less black. Change the color palette of the image display to binary and you'll see it in much better contrast.

[DjScribbles]

So, we've had some success, though not in the way I expected.

The core issue was that we were attempting to do an HSV threshold on an RGB color image we aquired from the camera.

I switched to acquiring an HSL image from the camera and performing an HSL threshold on it, and was able to get some meaningful results.

On the PC, when FTPing the firefox preview (and I'm pretty sure MS Paint) does properly display a binary bitmap as black and red, I didn't try writing out a jpeg this way to see if it worked that way though.


A follow up question, for the sake of discussion:
(note: We are using a green light ring for activating the retroreflective tape)
Are there any advantages to using HSV over HSL? Would it be worth figuring out how to use that colorspace? It doesn't seem to be directly available through ColorImage. We chose HSV semi-arbitrarily, so I'm not sure if it's worth the fight to go back to it, or if we should just tune for HSL.

[bob.wolff68]

If you're looking to change colorspace and see what happens, go back (or start using) NI Vision Assistant. After acquiring an image and beginning to process it, if you go to the "threshold" processing area in the 2nd tab, you can select "RGB", "HSL", "HSV" etc in a drop-down list and then play with the filtering min/max values. This will give you the ability to experiment and see what works best. Then use those values in your actual call in C/C++ once you're happy with it.

The white paper on target finding this year goes into HSL/HSV to a decent degree BTW.

bob

[DjScribbles]

The problem I encountered was occurring with the output from vision assistant, I switched to using the colorImage->threshold function after getting the black screen there. The vision assistant seems to perform some extra steps on the jpg you give it to put it into the proper color space, which doesn't get done in the generated c code.

Perhaps I need to close the loop on this whole fiasco, it maybe that it originally worked fine doing the conversion in the generated code, but combination of bad particle analysis decomposition and from writing my binary image as a jpeg caused it to look 'broken'.

But, throughout this, our vision assistant script has given us the expected result, while we were unable to get any results from the C++/c code (until switching color space).

[bob.wolff68]

So, if I read this right, you're on your way to health. Yes? If so, then we'll just close this out until there's something new or you get a rockin' great tracker!

bob