What is the actual 50% gray hex?

[es_91]

Using RGB () with 0-255 i wonder if a perfect 50% grey would require 127 or 128 since Windows wants to use 0,64,128,191,255 but shouldn't it be 0,63,127,191,255?

Since if it's $0 to $ffffff half should be $7f7f7f right? or $808080?

[AZJIO]

1-4, what is half 2 or 3?
1-3, is it 2 half? The average number is not half 3/2 = 1.5
gray? 999999 = gray. 99=99=99 = Rule for gray

50%
0-255 -> 127 (0-127, 128-255)
1-256 -> 128 (1-128, 129-256) (128+128=256)
Google: Gray 808080 or 7F7F7F
result

[mk-soft]

PureBasic Gray

Code: Select all

Debug Hex(#Gray)

[STARGÅTE]

25% * 255 = 63.75 , round , 64 = $40
50% * 255 = 127.5 , round , 128 = $80
75% * 255 = 191.25 , round , 191 = $BF

[BarryG]

Code: Select all

c=RGB(255/2,255/2,255/2)
Debug Red(c) ; 127
Debug Green(c) ; 127
Debug Blue(c) ; 127

[es_91]

25% * 255 = 63.75 , round , 64 = $40
50% * 255 = 127.5 , round , 128 = $80
75% * 255 = 191.25 , round , 191 = $BF

That puts it best. Thanks!

@mk-soft: PureBasic uses $808080.

But according to BarryG, a division to non-integer should always round down?

[normeus]

This will give you standard rounding:

Code: Select all

;Interesting
c=RGB(255/2.0,127.5,127.5)
Debug Red(c) ; 128
Debug Green(c) ; 128
Debug Blue(c) ; 128

Norm

[Olli]

I am such pasted to the past that I love the four (0,1,2 and 3) gray colours of the CGA standard, which can be translated by :

Code: Select all

Procedure cgaGray(x)
 x & %11
 x * 85
 procedureReturn RGB(x, x, x)
EndProcedure

I love it... 64-colours palette.

Good math demo stargate. Thank you

[Denis]

c=RGB(255 >> 1, 255 >> 1, 255 >> 1)
Debug Red(c) ; --> 127
Debug Green(c) ; --> 127
Debug Blue(c) ; --> 127

; who's right?
; it's going to keep me awake ...

[Piero]

[Tawbie]

Hi es_91,
If by saying 50% gray you mean a 50% linear light intensity on a typical sRGB LCD monitor, then you need an RGB value of about (188,188,188). sRGB does not scale linearly with light intensity. The code below shows a comparison of RGB(127,127,127) and RGB(188,188,188) alongside RGB(255,255,255). Clearly, RGB(127,127,127) is too dark to represent 50% linear light intensity, whereas RGB(188,188,188) looks about right.

Code: Select all

If OpenWindow(0, 0, 0, 600, 600, "50% Gray Test", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  If CreateImage(0, 600, 600)
    If StartDrawing(ImageOutput(0))
      DrawingMode(#PB_2DDrawing_Transparent)
      Box(0,   0, 600, 200, RGB(127,127,127)) : DrawText(100, 100, "RGB = 127,127,127", #White)
      Box(0, 200, 600, 200, RGB(188,188,188)) : DrawText(100, 300, "RGB = 188,188,188", #White)
      Box(0, 400, 600, 200, RGB(255,255,255)) : DrawText(100, 500, "RGB = 255,255,255", #Black)
      StopDrawing()
      ImageGadget(0, 0, 0, 600, 600, ImageID(0))
    EndIf
  EndIf
  
  Repeat
    Event = WaitWindowEvent()
  Until Event = #PB_Event_CloseWindow
EndIf

[SPH]

Between two positive numbers, there is a true midpoint.
Between 0 and 2, there is 1.
But between 0 and 255, there is 127.5 (so 127 and 128).

The choice is yours...

PS: If you consider white (255) to be a form of gray, then your perfect midpoint is 128.

[AZJIO]

I liked the wording: the gray in the negative gives itself away.

Code: Select all

x = $FFFFFF - $808080
Debug Hex(x)
x = $FFFFFF - $7F7F7F
Debug Hex(x)

[#NULL]

There is also the option of dithering, alternating pixels between 127 and 128 to visually approach an 127.5
I wouldn't see the difference with my eyes if I wouldn't know it but there is a slight shimmering/flickering to the dithering.
I reused the code by Tawbie:

Code: Select all

If OpenWindow(0, 0, 0, 600, 800, "50% Gray Test", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  If CreateImage(0, 600, 800)
    If StartDrawing(ImageOutput(0))
      DrawingMode(#PB_2DDrawing_Transparent)
      
      gap = 0
      ;gap = 1
      
      Box(0,   0, 600, 200-gap, RGB(127,127,127)) : DrawText(100, 100, "RGB = 127,127,127", #White)
      
      c1 = RGB(127,127,127) : c2 = RGB(128,128,128)
      ;c1 = #Black : c2 = #White
      
      Box(0, 200, 600, 200-gap, c1)
      For y = 200 To 400-1-gap
        For x = 0 To 600-1
          If (x + y) % 2
            Box(x, y, 1, 1, c2)
          EndIf
        Next
      Next
      DrawText(100, 300, "127.5 (127/128)", #White)
      
      Box(0, 400, 600, 200-gap, RGB(188,188,188)) : DrawText(100, 500, "RGB = 188,188,188", #White)
      
      Box(0, 600, 600, 200-gap, RGB(255,255,255)) : DrawText(100, 700, "RGB = 255,255,255", #Black)
      
      StopDrawing()
      ImageGadget(0, 0, 0, 600, 600, ImageID(0))
    EndIf
  EndIf
  
  Repeat
    Event = WaitWindowEvent()
  Until Event = #PB_Event_CloseWindow
EndIf

[es_91]

I thought about it. I think a monitor that shows black is not pushing-through any energy, thus has no value (0).

The first amount of energy is '1', the last is '255'. THEIR mid is (255-1)/2+1 = 128. It's not the mid value of the 'values', but the mid of the 'energetic states'.

So perhaps the mistake was to see '0' as an energetic state when it's actually as none-energetic as full opacity.

Of course, white ($ffffff) could be the opac value, too, but that would only make sense in a subtractive colour sheme.

Hope i came clear.