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
Thanks WLE
How about you show us the table. it's not clear from your description what it contains.
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.
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??
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'?
/*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'?
ASKER
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>>>>>>>>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?
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 ?
ASKER
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 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 ?
And the destination array ? Is that also unsigned ?
ASKER
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.