Prev: about culture and globalization
Next: FileSystemWatcher and open files
From: Jeff Gaines on 2 Apr 2010 03:43
On 02/04/2010 in message <18sar5piv0hjnb2h7adjpq341gg7eaatks(a)4ax.com> Tim
Roberts wrote:

>"Jeff Gaines" <jgaines_newsid(a)yahoo.co.uk> wrote:
>>
>>private int RGBColour(Color colTemp)
>>{
>> int intColour = colTemp.B * 255 * 255;
>> intColour += colTemp.G * 255;
>> intColour += colTemp.R;
>> return intColour;
>>}
>
>That's not correct. The color components are integers ranging from 0 to
>255. You need to multiply them by 256 to shift them into place, not by
>255.

I'm not shifting them, I'm making an integer out of the individual colour
components. I can promise you it has worked for many years :-)

>
>More efficient yet would be:
>
> int intColor = (colTemp.B << 16) | (colTemp.G << 8) | colTemp.R;

I'm sure there are better ways, as Peter said Color.ToArgb() might do it,
but this function was written long before .NET was a twinkle in anybody's
eye!

--
Jeff Gaines Dorset UK
It may be that your sole purpose in life is to serve as a warning to others.
From: Peter Duniho on 2 Apr 2010 11:26
Jeff Gaines wrote:
> On 02/04/2010 in message <18sar5piv0hjnb2h7adjpq341gg7eaatks(a)4ax.com>
> Tim Roberts wrote:
>
>> "Jeff Gaines" <jgaines_newsid(a)yahoo.co.uk> wrote:
>>>
>>> private int RGBColour(Color colTemp)
>>> {
>>> int intColour = colTemp.B * 255 * 255;
>>> intColour += colTemp.G * 255;
>>> intColour += colTemp.R;
>>> return intColour;
>>> }
>>
>> That's not correct. The color components are integers ranging from 0 to
>> 255. You need to multiply them by 256 to shift them into place, not by
>> 255.
>
> I'm not shifting them, I'm making an integer out of the individual
> colour components. I can promise you it has worked for many years :-)

No doubt the error in the algorithm is hard to perceive in real-world
usage. But it's there.

Of course, it all does depend on how the integer is consumed. But I
have _never_ seen any code that has the reverse algorithm (i.e. divide
by 255 iteratively to retrieve each component). Any normal consumer of
the output of the code you posted, one that follows the usual "RGB
stored as 32-bit integer" rules, is going to see a variety of unexpected
results.

For example, if your RGB value is (0, 1, 0), then the output of the
algorithm is 0x000000ff; if that is then decomposed in the usual way
back to an RGB value, by extracting the lowest three bytes from the
32-bit value, red as least-significant-byte, then the resulting RGB
becomes (255, 0, 0). All of the sudden, a color that was practically
black becomes solid, bright red.

>> More efficient yet would be:
>>
>> int intColor = (colTemp.B << 16) | (colTemp.G << 8) | colTemp.R;
>
> I'm sure there are better ways, as Peter said Color.ToArgb() might do
> it, but this function was written long before .NET was a twinkle in
> anybody's eye!

Age is no insurance against error. ;)

Pete
From: Jeff Gaines on 2 Apr 2010 12:23
On 02/04/2010 in message <uSbAOjn0KHA.6108(a)TK2MSFTNGP06.phx.gbl> Peter
Duniho wrote:

>For example, if your RGB value is (0, 1, 0), then the output of the
>algorithm is 0x000000ff; if that is then decomposed in the usual way back
>to an RGB value, by extracting the lowest three bytes from the 32-bit
>value, red as least-significant-byte, then the resulting RGB becomes (255,
>0, 0). All of the sudden, a color that was practically black becomes
>solid, bright red.

It doesn't get decomposed.
It's used for the various functions in cards.dll, I don't think that's
included with Windows any more, I use a copy from a pretty old Windows
install.
I can't find the original notes but it was certainly the standard way of
turning a Color into what cards.dll expected - whatever that was :-)

--
Jeff Gaines Dorset UK
That's an amazing invention but who would ever want to use one of them?
(President Hayes speaking to Alexander Graham Bell on the invention of the
telephone)
From: Peter Duniho on 3 Apr 2010 00:15
Jeff Gaines wrote:
> On 02/04/2010 in message <uSbAOjn0KHA.6108(a)TK2MSFTNGP06.phx.gbl> Peter
> Duniho wrote:
>
>> For example, if your RGB value is (0, 1, 0), then the output of the
>> algorithm is 0x000000ff; if that is then decomposed in the usual way
>> back to an RGB value, by extracting the lowest three bytes from the
>> 32-bit value, red as least-significant-byte, then the resulting RGB
>> becomes (255, 0, 0). All of the sudden, a color that was practically
>> black becomes solid, bright red.
>
> It doesn't get decomposed.

Unless it's a palette index, it does. And you don't create palette
indices by composing 8-bit RGB values into a single 32-bit int.

> It's used for the various functions in cards.dll, I don't think that's
> included with Windows any more, I use a copy from a pretty old Windows
> install.

cards.dll uses RGB as the color value.

In your first reply, you didn't make clear you were actually using that
value for the cards.dll library. With that additional information, we
can be certain that your code is not correct for the application you
used it for.

As I mentioned before, most of the time the error will be difficult to
notice. But it's there.

Pete
From: Jeff Gaines on 3 Apr 2010 04:00
On 03/04/2010 in message <uP83NRu0KHA.4412(a)TK2MSFTNGP02.phx.gbl> Peter
Duniho wrote:

>>It doesn't get decomposed.
>
>Unless it's a palette index, it does. And you don't create palette
>indices by composing 8-bit RGB values into a single 32-bit int.

I have no idea now what it represents, but it works and it was the
standard way of turning a Color into whatever cards.dll needed.

>In your first reply, you didn't make clear you were actually using that
>value for the cards.dll library. With that additional information, we can
>be certain that your code is not correct for the application you used it
>for.

The thread is about the cards.dll library, see the OP!

--
Jeff Gaines Dorset UK
If you ever find something you like buy a lifetime supply because they
will stop making it
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: about culture and globalization
Next: FileSystemWatcher and open files