Printable View
Hello everyone.
I have a bit of an issue here. Say I have a textbox with a variable background color, changeable by the user. How can I set the foreground color to be visible at all times?
I can use the inverted color (255 - Color.R) but this fails at the gray (128/128/128) color. Any suggestions?
http://i708.photobucket.com/albums/w...ller/color.jpg
Depends on your sideboards. One thing you could do is say that the forecolor is either white or black. Take the RGB, convert to an integer, and if the integer is above X, then the forecolor is black, otherwise it is white. The difficulty would be figuring out what X should be, but I think that you can say that it is 2^24, or 16777216. Of course that comes out to 128,0,0. So that is entirely dependent on the R value.
An alternative would be to average the three bytes and make X 128. Therefore, if the average of the three colors is greater than 128, then the forecolor is black, while if the average is below 128, the forecolor is white. A bit more of a calculation there, but not too bad. You could speed it up a bit by getting rid of the /3 part of the average. Just summing the three bytes and setting X to 384 should have the same effect.
That is a simple yet working solution, but the problem gets deeper afterwards.
I see many games use either of the two extremes:
- let the user choose the crosshair color
- use an inverted crosshair color
Both are nice, but neither of the two are completely working.
The background can change rapidly, and using a blocky method would not look nice. Background information:
I have a textbox with as background the color at the mouse cursor, and as text the RGB value. If the user moves it's mouse over a greyish area it would flicker real badly between black and white. It needs to be a smoothed solution, which is I have never seen.
I'll keep the "binary method" in mind for when I have a richtextbox with variable background.
EDIT
I believe it has something to do with a different color format, HSV I believe.
Also, you could use a bright green on a grey surface, which would distanct the two colors a lot better.
Since the difference between grey and green is large I have no idea of how to do it.
You started out talking about a textbox, but now you seem to be talking about an image. That's a whole different issue, and probably isn't one that can be solved all that well.
One thing that I have seen is that the cursor be large on a detailed image. If the cursor is a largish area of a single color, while the background has no large areas of constant color, then the cursor will be somewhat visible regardless of what color it is over.
Another alternative is to have a certain color for the cursor that is not found to any extent in the image, but that kind of thing depends on the color schema of the program. As an example, the game Oblivion uses a gold cross as a cursor. There is almost no use of that color anywhere in the game, so the cursor is always distinctive on the background, whatever the background happens to be. However, the cursor is also relatively large when compared to the detail of the underlying images, and the cursor is always located in the center of the screen, so the situation is greatly simplified.
Not really an image, just a changing backgroundcolor as seen in my first post. And in this case there is no color that never exists; it always exists since any color on the screen is used.
I basically need an algorithm of some sort that returns the "brightness opposite" of a certain colour.
In that case, I would say that you already have one, except that it fails in a certain situation where the three bytes are all very near 128. Therefore, if you test for that special case and handle it differently, such as writing black in that case, then you can use the technique you already have for all other cases.
Another common use is have a drop-shadow effect or bezel of a different color around the main one.
Also, i had a similar situation to yours at finding a reverse color. I ended up simply xoring the color by &H777777. This would give me a color that was always visible and contrasted and it's one line.
I'll try to make a combination of the two:
- first generate a negative (inverted) version of the colour
- then calculate the color difference (rgb color differences added)
And maybe factorize the colour with the difference. This way the brightness would turn black if the difference is very small.
I'll post a result when I fully tested this; I made this from scratch while writing the reply. :bigyello:Code:Dim c As Color = Color.Gray
Dim inv As Color = Color.FromArgb(255 - c.R, 255 - c.G, 255 - c.B)
Dim diff As Integer = 0
diff += Math.Abs(c.R - inv.R)
diff += Math.Abs(c.G - inv.G)
diff += Math.Abs(c.B - inv.B)
Dim factor As Double = diff / (255 * 3)
inv = Color.FromArgb(inv.R * factor, inv.G * factor, inv.B * factor)
EDIT
Wow, that does seem to work nicely. Looped through all color values and all colors gave a contrast. Function(s):
Or this:Code:Public Function GetInvertedColor(ByVal c As Color) As Color
Return GetInvertedColor(c.R, c.G, c.B)
End Function
Public Function GetInvertedColor(ByVal R As Integer, ByVal G As Integer, ByVal B As Integer) As Color
Dim inv As Color = Color.FromArgb(255 - R, 255 - G, 255 - B)
Dim diff As Integer = 0
diff += Math.Abs(R - inv.R)
diff += Math.Abs(G - inv.G)
diff += Math.Abs(B - inv.B)
Dim factor As Double = diff / (255 * 3)
inv = Color.FromArgb(inv.R * factor, inv.G * factor, inv.B * factor)
Return inv
End Function
Code:Public Function GetInvertedColor(ByVal R As Integer, ByVal G As Integer, ByVal B As Integer) As Color
Dim diff As Integer = 0
diff += Math.Abs(R - (255 - R))
diff += Math.Abs(G - (255 - G))
diff += Math.Abs(B - (255 - B))
Dim factor As Double = diff / (255 * 3)
Return Color.FromArgb((255 - R) * factor, (255 - G) * factor, (255 - B) * factor)
End Function
May be it is possible to simplify it, but for now this is it.Code:Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
Dim bmp As New Bitmap(1, 1)
Dim g As Graphics = Graphics.FromImage(bmp)
g.CopyFromScreen(Cursor.Position, New Point(0, 0), New Size(1, 1))
g.Dispose()
Dim c As Color = bmp.GetPixel(0, 0)
Me.BackColor = c
PictureBox1.BackColor = GetInvertedColor(c)
End Sub
Maybe this is just a footnote, but I'd like to suggest an alternative method for getting a contrast color: instead of inverting the r, g and b bascially you add Hex 7F7F7F to the integer color value, for example:
The result is a color that is always visibly different from the background color, be it black, gray, white or anything else. The main merit of this is that it is better for the environment because it saves lines of VB.Net;). It will also be more efficient. That won't matter if you are changing only a single pixel, but it could matter if you were making a custom cursor that you want to contrast pixel for pixel with the background. In that case you wouldn't use ToARGB and FromARGB but work directly with an integer array.Code:Private Function GetContrastColor(backgroundColor As Color) As Color
Dim backColor As Integer = backgroundColor.ToArgb
Dim newColor As Integer = (backColor + &H7F7F7F) Or &HFF000000
Return Color.FromArgb(newColor)
End Function
The logic is as follows. If you add 127 (hex 7F) to the blue byte, it will change the value to (originalValue+127) Mod 256. There could be a carry over to the Green byte but that will only affect the last bit so it won't be important. The same applies to green and red, but not to the alpha byte. In many circumstances you don't want to change that because Alpha <255 requires alpha blending and will be slower. The above example makes sure the alpha is always 255, but it could easily be changed to preserve the original alpha or set another chosen alpha.
BB
that is in fact exactly what xoring by &h7f7f7f does, except you took into account alpha.Quote:
Originally Posted by boops boops
However, working with them as numbers as you do above, you will be wrapping your total into the alpha channel if the original number is large. Stick to xoring.
Hold on a sec, using XOR does not guarantee a contrasting colour and one has to be careful as to which value to choose as some values work better than others eg. &H7F7F7F is a bad choice... &H3F3F3F XOR &H7F7F7F = &H404040. &H808080 on the other hand is a good choice.Quote:
Originally Posted by Lord Orwell
Edit: XOR &H808080 is the best choice. It guarantees a difference of 128.
My footnote: It had to be smoothed out; using logic like (x)or will not work in my case, since it causes flickering.
Bergerkiller, I don't know if you have noticed but your code fails with dark colours.
how could it cause flickering? it doesn't modify the number any differently than any other way.
At first I had my doubts, but you and Lord Orwell are right. XOR &H808080 rules! Then there's no need to correct the alpha byte. BBQuote:
Originally Posted by Milk
That flickering is a result of something else, and should be examined with a bit of debugging. The color should change only one time, and XOR should be at least as fast as any other solution. I like it better than anything I had suggested, after thinking it over a bit. However, if you are getting flickering with XOR, that suggests that your code, which should run only once a loop, is actually running more often. While it is not certain that there is some problem you are missing, the flicker certainly suggests that there is.
By the way, how about XORing with &HBADA55 ?
It's an ugly colour with a great name.
@milk you may be right, but I'm not sure.
And flickering since the color CHANGES rapidly. The color will change 20 times / second for the least, and if the color changes between 127/128/129 it would flicker badly. Not a nice solution. I do not mean an infinite loop is happening, I mean it is not smooth. (X)Or is not a solution, else I wouldn't have asked it. :)
So you aren't looking for an exact answer, but kind of playing a game of color keepaway.
Inherit from TextBox and set its (Protected) DoubleBuffered property to True. BB
I don't think that will work in this case. Changing colors 20 times a second would mean that the changes would be so fast that they would barely register, and therefore would be just a flicker, but double buffering shouldn't help because these are real changes. The program has a chance to do the full and complete drawing in each frame, which means that double buffering will see each draw cycle as being complete and flip the buffer. Unfortunately, it will flip the buffer at a rate fast enough for the user to see a change at 20fps, which is well within the range where they will see it, if only briefly enough to register as flicker.
EDIT: It will help in one regard, as the old image won't get blanked each time, but 20 fps is too fast to be a smooth transition, and too slow to be ignored.
To make it clear:
http://www.vbforums.com/images/ieimages/2011/04/1.png
It's the same idea, only for a textbox located somewhere else. The rgb value is displayed in there, and I need the text to be visible at all times. The cursor can change the color rapidly (+- 20 fps), thus an (x)or would cause flickering when the user moves it's cursor over a greyish area on the screen. And it wouldn't look nice in games either. It must be smoothed out, which means an color which is somewhat "the opposite" of another color.
What is the opposite colour of grey? It would be grey, but that makes no sense. It would have to be black or white, or maybe green?
All other colors are easily solved using a negative, but what about the neutral colors?
I tried to solve it by calculating the difference, and if this is too low, it must do something extra.
In this case I adjusted the brightness, but this just changes the color value at which it no longer works, as Milk mentioned.
I think the opposite of grey is probably gray.
As long as it is pleasing to the eye and viable in speed, then you have a good solution. All the rest is just discussion.
I think I know what you mean. When you move across a smooth gradient the rgb-shifted color (whether with addition or XOR) can suddenly flip to totally different hue. That doesn't look nice.
Here's another suggestion: use the inverted color. (In fact you can do that with XOR &HFFFFFF.) But add a few opaque black and white pixels to the cursor so that at least something will show up on plain gray. You can get a line of neatly spaced pixels by drawing a line with a Pen with a suitable custom DashStyle. I'll try to work out an example if you like.
BB
Well the problem is that it is for a textbox forecolor, so I can't draw additional points in it unfortunately. And yes, on a gradient it would suddenly flip (or flicker in my case). I'll see if I can use the difference differently so it works on any color...
Do you really need to use a text box? If the image you posted in #1 is anything to go by, you could just as easily use a picture box and draw the letter(s) with GraphicsPath.AddString/Graphics.DrawPath or Graphics.DrawString. Then you would have complete artistic freedom, so to speak:cool:. For example, you could use FillPath to fill the letters with a solid color and then DrawPath to draw the outline in a different color. BB
No the user must be able to copy text from the textbox as well, the color updates while the cursor is not in "move mode" in case the color is "animated" (in a video window etc.)
i think i know what's going on. He's reading and writing directly instead of manipulating an image. If he xors the image, he'll get a great result, but then he goes and xors the new image instead of leaving it alone.Quote:
Originally Posted by Shaggy Hiker
The good solution would be to manipulate the xoring on an unmodified original and then write to the display.
What i don't understand is why he's not getting flickering with other methods.
I would like to see the complete code for debugging.
Sigh. :rolleyes:
I'll give a full explanation so you can test it.
1. Make a new Windows Forms application
2. Add a timer (enabled) and a panel centered in the middle. The form background must be visible.
3. Add the following code for the timer_tick:
4. Add the following (uncompleted) function:Code:Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick
Dim bmp As New Bitmap(1, 1)
Dim g As Graphics = Graphics.FromImage(bmp)
g.CopyFromScreen(Cursor.Position, New Point(0, 0), New Size(1, 1))
g.Dispose()
Dim c As Color = bmp.GetPixel(0, 0)
bmp.Dispose()
Me.BackColor = c
Panel1.BackColor = GetInvertedColor(c)
End Sub
5. Adjust the interval as you likeCode:Private Function GetInvertedColor(ByVal c As Color) As Color
Return Color.FromArgb(255 - c.R, 255 - c.G, 255 - c.B)
End Function
6. Launch the application and see how the form color changes based on the cursor pointer. Aim the mouse at a color scheme, like this one:
http://docs.eiffel.com/sites/docs.ei...og-windows.png
http://www.craigfineportraits.com/fo...olor_chart.jpg
My code failed at greyscale 10.
The panel may not flicker or change all of a sudden, it must be smoothed.
Adding additional colors is not an option, it must be a single function producing the opposite color, so it is ALWAYS visible on the background.
In games that use inverted crosshairs they try to use as less grey as possible so no one really bothers, but in my case any color can exist.
It is not just for a textbox text to remain visible, it would be great for other purposes as well.
EDIT
And I just noticed
Seemed to work, but not entirely. Hover the mouse between greyscales 6 and 7, you'll see it switching between white and black rapidly.Code:Private Function GetContrastColor(backgroundColor As Color) As Color
Dim backColor As Integer = backgroundColor.ToArgb
Dim newColor As Integer = (backColor + &H7F7F7F) Or &HFF000000
Return Color.FromArgb(newColor)
End Function
The same happens when moving the mouse over the yellow fade in the color dialog.
Thanks for posting more details. Unfortunately I can't see where a TextBox comes into it.
Any method using byte value shifting (XOR &H808080 or + &H7F7F7F) is going to cause colour flipping.
Suppose you have pixel with color [0, 128, 50] and you add 127 (&H7F) to each byte. The contrast colour is [127, 255, 177]. Now suppose the next pixel has a color which differs only by 1 in the G value: [0, 129, 50]. The contrast color (ignoring the carry) will be [127, 0, 177], which differs by 255 in the G value: obviously a totally different colour. This kind of thing can happen however much you add to each byte.
In the case of XOR, I find it easier to think in bits. Suppose one pixel has the r byte = 00001111. XORing with &H80 (=11110000) will give the contrast value 11111111 (=255D). Now suppose the next pixel differs only by +1 in the r byte: 00010000. XORing with &H80 will now give 11100000 (=224) which is 31 less. It's not as much as in the adding method, but it's enough to upset the balance between r, g and b and produce a wholly different colour.
If you use the inverse, on the other hand, this won't happen. A difference of +1 in one byte of adjacent pixels will always result in a difference of -1 in the inverse byte. So there won't be a sharp transition in the inverse colour.
It must surely be possible to find a way to avoid the inverse Gray =Gray problem without colour flipping, but I'll have to sleep on it.
BB
what result do you get when
(backColor + &H7F7F7F) Or &HFF000000
is replaced with
(backColor& XOR &H7F7F7F) Or &HFF000000
You don't need &HFF000000 with XOR because there is no carry bit to affect the alpha byte. XOR &H7F7F7F gives a less intense contrast but it also has colour flipping. I've been trying XOR &HABCDEF; it looks promising. BBQuote:
Originally Posted by Lord Orwell
Light colours show up better on dark backgrounds, dark colours show up better on light. It does not matter what fancy calculations you do there are only really two options for finding a contrasting shade. You either have a smooth transition where at some point the contrasting colour is of equal luma to the background (hard/impossible to see, not colour blind friendly), or a sharp transition where at some point the contrasting colour flips from one shade to another.
Here is a suggestion which you may or may not like, it returns either black or white but it will only flip the colour if it is outside of a dead zone otherwise it returns the last colour used. It will flip but not flicker.
Regarding exclusive Or, you can easily work out the maximum/minimum contrast an XOR value will give. The maximum is the sum of all the bits and the minimum is the value of the most significant bit minus all the other bits.Code:Private Shared Function ContrastColour(colour As Color, oldColour As Color) As Color
Dim luma__1 As Integer = Luma(colour)
If luma__1 > 159 Then
Return Color.Black
ElseIf luma__1 < 96 Then
Return Color.White
Else
Return oldColour
End If
End Function
Private Shared Function Luma(c As Color) As Integer
'there are loads of Luma algorithms out there
'most do not take into account gamma compression
'this is just a rough one
Return (c.R * 3 + c.G * 4 + c.B * 2) / 9
End Function
Code:Hex Bin Max Min
FF 11111111 255 1 <--inverts channel, no flip
7F 01111111 127 1
80 10000000 128 128 <--equivalent of adding/subtracting 128
40 01000000 64 64
C0 11000000 192 64
9C 10011100 156 100
AA 10101010 170 86
that's true but it's not why i listed it. It was to ensure the alpha byte is maxed out.Quote:
Originally Posted by boops boops
I'll drink a pint of that, Milk. I was also coming to the conclusion that you have to choose between continuity+dead points or colour flips. You are right about it being the luma that matters. I thought I would try out a variation of your code with intermediate levels of gray:Quote:
Originally Posted by Milk
I find the resulting contrast is always good enough and the transitions seem less abrupt. I'm using different Luma coefficients. It seems that people deemphasise the blue much more for modern RGB monitors, although exact published values vary. I don't suppose it matters much here.Code:Private Shared Function LumaContrast(color As Color) As Color
Select Case Luma(color)
Case Is > 158 : Return color.Black
Case Is > 135 : Return color.FromArgb(50, 50, 50)
Case 115 To 134 : Return color.FromArgb(80, 80, 80)
Case Is > 96 : Return color.FromArgb(135, 135, 135)
Case Is > 60 : Return color.FromArgb(180, 180, 180)
Case Else : Return color.White
End Select
End Function
Private Shared Function Luma(c As Color) As Integer
Return (c.R * 3 + c.G * 6 + c.B * 1) \ 10
End Function
On my system, text boxes flicker when you change their background colour, even if double buffered. Picture boxes don't flicker when painted to look exactly the same.
BB
Nice one Mr BB, yours is a nicer function. I just noticed that developer fusion has messed with my variable names luma__1 is not my choice.
Regarding luma, I had a think about it last night and I came to the conclusion that I don't really understand it. I pulled them numbers out of the air. Given the wide variety of coefficients flying around I think a lot of people don't really understand it either. I created a small app to help me choose coefficients where I rendered a bunch of 1 pixel wide/high lines in alternate colour/grey stripes. I then adjusted the grey shade to find one where the stripes were hardest to see... this all worked a treat, I found a distinct shade of grey for each channel, the only problem was that if I added these up I got something like 384 (as opposed to ~255). I was going to check later if that observation fits better with the euclidean algorithms.
The coefficients used in lumen calculation are based on measurements of human eye sensitivity to different colors. In practice monitor RGB values vary and so do people's eyes so they are only "typical" values anyway. The usual factors you see for linear averaging are either:Quote:
Originally Posted by Milk
NTSC: 0.299, 0.587, 0.114
or
RGB: 0.3086, 0.6094, 0.0820
I think I found these in Wikipedia somewhere. The NTSC coeffs. are based on typical CRT monitor phosphors of 1953 but you still see them widely used. The RGB coeffs. are apparently based on more modern RGB monitors. For present purposes we can round both these to (3, 6, 1)/10. (Dang, I'll have to edit my previous post again:mad:). I should think the higher precision is needed for photo work.
Some people favour an RMS average instead of a linear one. See here: http://alienryderflex.com/hsp.html; this page does some comparison tests which might be like what you were trying to do. Funnily enough, it ends up finding the NTSC coefficients best in an RMS calculation: go figure:confused:.
BB
Ah luminance, that was the word. :p
Then indeed I think I need to calculate the luminance value of the RGB color inputted, and return a grayscale opposite of this luminance. Or may be a blue/red/greenscale. I'll look into it some more.