Link to home
Start Free TrialLog in
Avatar of Wanderinglazyeye
Wanderinglazyeye

asked on

unexpected result

I wanted someone to help interpret my results as I don't really understand them. I created an LUT table that is applied to the Hue vales of a matrix. It works fine, isolates the desired range of colors. Now, if I fill the table with the range of color (100 - 120) and the rest of the table with 255 instead of 0, the image is then inverted. It goes from a light object in black background to a black object in white background once the other non-range values are changed from 0 to 255.  It's a desirable result but I don't understand it because the cvLUT function states that it will index pixels only  in the range. So why does a hue value of 255 cause inversion? Not to mention that the Hue value is multiplied by 2 with reconstruction of the image (Hue is divided  by 2 to fit into an 8bit number.

Thanks WLE
Avatar of grg99
grg99

How about you show us the table.  it's not clear from your description what it contains.

Avatar of Infinity08
Are you sure that it's inverted or does it only look like it is ? In other words, it's probably only the background that changes from black to white, and the other colors (100-120 range) stay the same, but just look lighter/darker depending on the background. That's called an optical illusion ... can you check that that's not the case ?
That is pretty much the result that you should expect. Is the region [100;120] different regarding the outcome when doing so? If not everything is the way it should be.
Avatar of Wanderinglazyeye

ASKER

The region [100;120] is not the same. When I run it with the table of the range [100;120] and 0 in all other places, the background is black and the red objects are white. When I add the LUT table (below) the background is white and the range is dark. I rechecked it.


White background/ dark objects

255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      101      102      103      104      105      106      107      108      109      110      111      112      113      114      115      116      117      118      119      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255      255

Dark objects/white background:
Writing sat val to a file.
0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      101      102      103      104      105      106      107      108      109      110      111      112      113      114      115      116      117      118      119      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      0      

Any further thougts??
Hmm, from the docs:

 /*F///////////////////////////////////////////////////////////////////////////////////////
 //    Name:    cvLUT
 //    Purpose: Performs lookup-table transform: dst(x,y) = lut[src(x,y)]
 //    Parameters:
 //      srcarr - the source array: 8u or 8s type
 //      dstarr - the destination array of arbitrary type,
 //      lutarr - the LUT array. The same type as the destination array,
 //               contains 256 entries.
 //    Note:
 //      if the source array has 8s type, the modified formula is used:
 //      dst(x,y) = lut[src(x,y) + 128]
 //F*/
 OPENCVAPI  void cvLUT( const CvArr* srcarr, CvArr* dstarr, const CvArr* lutarr );

Especially

 //    Note:
 //      if the source array has 8s type, the modified formula is used:
 //      dst(x,y) = lut[src(x,y) + 128]

seems to play a role here. What are the results for other values but '0' and '255'?
Ok, it looks like the pixel values of the Hue image  in the table with the white background (255) is being written as -1, which is unexpected. I do know that the Hue value is divided by 2 upon conversion to fit in an 8 bit value. 255 is 8bit, but must exceed some threshhold, becuase you can't have a Hue (upon conversion back to BGR of 510 - it doesn't exist).  So why is the cvLUT function writing a (-1) pixel value when the LUT has a value of 255?
ASKER CERTIFIED SOLUTION
Avatar of jkr
jkr
Flag of Germany image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
>>>>>>>>seems to play a role here. What are the results for other values but '0' and '255'?

If I use 250 instead of 255 the filling number is -6. The isolated color values are between 100 - 120 as expected. I guess my question can be narrowed to this: if pixels are indexed only if they fall in the range of 100-120, why are non-range pixels being indexed at all such as in the case of -1 or -6? I don't mean to press the question, but this is really interesting to me this behavior. It can be manipulated. Are all pixels being indexed?
Are ypu passing a signed or unsigned byte array?
Your example shows the expected behavior, so there must be something I'm missing ... Which values are incorrect ? And in which cases ?
From OpenCV:

The function cvLUT fills the destination array with values from the look-up table.
----------------------------------------------------------------------------------------------------

The LUT is an unsigned array. The source array to which the LUT array is being applied is unsigned as well.

>> The LUT is an unsigned array. The source array to which the LUT array is being applied is unsigned as well.

And the destination array ? Is that also unsigned ?
Let me correct:I don't whether the source array is unsigned or signed. Sorry. This array is generated by cvPixToPlane which takes an BGR picture and splits it into 3 planes - H, S, V (Hue, Saturation and Value). I am then applying  seperate LUT arrays(unsigned) to each plane to a destination array (allocated as unsigned).
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial