GRIP
GRIP copied to clipboard
WPIRoboticsProjects
HSV Hue Should be invertible
You should be able to invert the hue value selection from within GRIP. Otherwise you can't select the red range of colors.
- I suggest that this is painful enough of an issue to warrant higher priority.
- Before seeing this posted I thought a circle/spinner type of input would be nice - a "color wheel" with two handles to drag around the circumference for selection. The wheel doesn't have to be colorful but it would be nice.
- I can live with straight line selection if it's obvious that the 2 ends are selected as opposed to the middle. thanks for adding this function - it's important.
The problem with this is that there is no good UI element that works like that. Neither controls FX or the base JavaFX library don't have a UI element like that.
I'm not really feeling up for writing a completely custom UI element for this. http://www.oracle.com/technetwork/java/javafx/community/3rd-party-1844355.html
Anyone who has designed JavaFX UI elements before and wants to take a crack at that come chat with us in the gitter chat.
Otherwise we could probably add a simple checkbox that inverts the range of values output.
Lets see if someone on the ControlsFX team wants to do this: https://bitbucket.org/controlsfx/controlsfx/issues/683/invertible-rangeslider
This is a bit ugly, but a possible workaround is to use two HSV filters, one for each end of the spectrum, and combine them with bitwise or.
Also, might I suggest bitwise not, and, and or be renamed to invert, intersection, and join, respectively?
Yes, adding two filtered images together is what I have been doing. Regarding your suggestion for the inverse: If you want say the reds from 355 degrees to 5 degrees, you can do the negation of the filtered image from 5 degrees to 355 degrees. The problem is the multi-dimensional aspect of HSV. I'm no color space expert and could be wrong but my intuition says that you can get the two red hues through the simple inverse of cyan but your desired saturation and value of red is not the inverse of any single saturation and value. Say you want red saturated from 20 to 30. The inverse is 0 to 20 plus 30 and beyond. Same for the values so you need two value filters for each of the two saturation filters. That's four filters - we are losing ground here. It does seem like OpenCV could have included this circular thresh-holding region (passing through 0) for efficiency since the data are right there for its use. Patching the function as an external add-on to OpenCV is ugly as you say. GRIP might make it easier to use by packaging the multiple filters but GRIP still has to generate OpenCV code - two filters added together.
If we want to implement this in GRIP, there seems to be a workaround for the UI element proposed by the controls FX team.