[wxPython-users] HitTest for Floatcanvas

[Christopher Barker]

Christian Blouin wrote:
> 	[Still staring at my screen in disbelief] I ran Chris's test and it
> failed most of the tests! However, I know now why it fails. I did had to
> change the color depth of my display to 16 bit to run a wargame a few days
> ago, coinciding with the beginning of this annoying bug. If I switch back to
> 32 bit display, chris's test works in 100% of the cases as expected.
> 
> 	Sooo, 16bit display causes woes as it looks like there is some
> rounding done, which cause one of the color channel to be off by a single
> digit. Did this behavior for floatcanvas picking was reported before?

I did try to accommodate this in the code, but apparently did not test 
it well enough. Here's the relevant code (in FloatCanvas.py)

def _colorGenerator():

     """

     Generates a series of unique colors used to do hit-tests with the Hit
     Test bitmap

     """
     import sys
     if sys.platform == 'darwin':
         depth = 24
     else:
         b = wx.EmptyBitmap(1,1)
         depth = b.GetDepth()
     if depth == 16:
         step = 8
     elif depth >= 24:
         step = 1
     else:
         raise "ColorGenerator does not work with depth = %s" % depth
     return _cycleidxs(indexcount=3, maxvalue=256, step=step)


so if depth == 16, it's skipping every 8 values, to make sure the colors 
are distinguishable at that bit depth. It probably does work it terms of 
making the colors unique, but it's not providing colors that can be 
exactly represented by 16 bits. I'm not entirely sure how 16 bit color 
works. 16 isn't divisible by 3, so how many bit are there for each 
color? I suspect that to so this right, you'd need to integrate through 
the possible colors properly, which requires one to know how they are 
represented. I see this, which I expect explains the problem:

"""
16 bit highcolour
Human eyes are more sensitive to green light. The greens are easier to 
see than the reds, and the blues are almost impossible to see.
Human eyes are more sensitive to green light. The greens are easier to 
see than the reds, and the blues are almost impossible to see.
When all 16 bits are used, one of the hues (usually green, more on next 
paragraph) gets an extra bit, allowing a 64 levels of intensity for that 
hue, and a total of 65536 available colours. There is a problem with 
doing this because the green channel can have a different value than the 
other two. Suppose we wish to encode the 24-bit color rgb(40,40,40) with 
16 bits. 40 in binary is 00101000. The red and blue channels will take 
the 4 most significant bits, and will have a value of 0010, or 2 out of 
32. The green channel, with 5 bits of precision, will have a value of 
00101, or 5 out of 64. Because of this, the color rgb(40,40,40) will 
have a slight green tinge when displayed in 16 bits.
"""
from: http://www.answers.com/topic/16-bit-color

Since it says that Green is "usually" the one with the extra bit, I'm 
not sure we can count on that.

A hack I can think of at the moment is to use a MemoryDC to find your 
color: add an extra layer that does DrawPoint, then GetPixel, and use 
that resulting value, instead of the one you started with. This would 
slow down the process of bit, but should be reliable.

I'd love to hear of a better solution!

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov