I want to develop, as a side product of my Mississippi Paddle Wheel
Riverboat, a small Windows program that can show the various colors of a
Pov-Ray color_map.

Having to use the late after-work evening time before going to bed, as
usual, also as usual my head is already a bit slow and tired. I am
asking around here, how to convert the usual COLOR RGB float values of
POV-Ray for red, green and blue into the integers for color definitions
that go from 0 to 255.

As I say, my head is heavy already and I just cannot get that formula by
myself, what a shame. But that's how it is. Can anyone assist with the
mathematical formula? Thanks.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

Sven Littkowski <I### [at] SvenLittkowskiname> wrote:
> I am
> asking around here, how to convert the usual COLOR RGB float values of
> POV-Ray for red, green and blue into the integers for color definitions
> that go from 0 to 255.

Usually I'm converting from some other program's color-picking output, so I do
<126, 40, 83>/255

So since you'll be going the other way - just multiply by 255.

Post a reply to this message

Thanks. I was irritated, as in Photoshop the 256bit integers are no
floats, but when simply multiplying, they are often enough still floats.
I might have to round these numbers then, I guess. But that means losing
exactness.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

Example:

color rgb < 0.4748656, 0.3364377, 0.7790974 >

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Post a reply to this message

On 04/27/2018 02:56 PM, Sven Littkowski wrote:

 > I might have to round these numbers then, I guess. But that means losing
 > exactness.
 >

Well, yeah. That is the nature of the beast.  floating point (a double) 
gives you 52 bits of precision and integer color "256" is 8 bits.

I wouldn't worry about it. The human eye can't really tell the 
difference between RGB(121,85,198) and RGB(122,85,198).


> Example:
> 
> color rgb < 0.4748656, 0.3364377, 0.7790974 >

R = 0.4748656 * 255   = 121
G = 0.3364377 * 255   =  85
B = 0.7790974 * 255   = 198


(I never understood why the x87 uses 80 bit numbers internally, to 
minimize rounding error in calculations, but only allowed inputs and 
outputs of 64 bits. Why can't I have all those bits?)

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

The bare formula would be to simply multiply the vector by 255 (not 256, because
0 to 255 makes 256 entries, total.)

(A full 5-component vector as an example...)
#declare BB = <.327,.586,.902,.431,.202>;
#declare BB_LARGE = BB*255;
// To test this...
#debug concat("\n","BB_LARGE = <",vstr(5,BB_LARGE,", ",0,3),">","\n")

another example...
#declare CC = <0,1,.5>;
#declare CC_LARGE = CC*255;
// to test this...
#debug concat("\n","CC_LARGE = <",vstr(3,CC_LARGE,", ",0,3),">","\n")

To pick out just one of the values, you would use dot notation--
    .red, .green, .blue, .filter, .transmit--
#declare BB_LARGE_FILTER = (BB_LARGE.filter);
// To test this...
#debug concat("\n","BB_LARGE_FILTER = ",str(BB_LARGE_FILTER,0,3),"\n")

If you want to eliminate the fractional parts to get just the integers, you
could use POV-Ray's built-in functions like int, floor, or ceil. Like...
               int(BB_LARGE.filter)

But the integer results-- using either of the three function choices-- may be
'one integer higher or lower' than what you want. You may have to decide in
which 'direction' to go.. For example: if BB*255 turns out to be
               <.999,0,254.999,0,128.000>
then int(BB_LARGE.red) would be 0.000-- because int 'rounds toward zero'; and
int(BB_LARGE.blue) would be 254, not 255. That's the same result you would get
when using floor. Using ceil(...) instead would have a similar but opposite
effect-- ceil(BB_LARGE.red) would be 1.000, while ceil(BB_LARGE.blue) would be
255. BUT, if BB_LARGE.red happended to be .001, ceil would still make it 1.000.

Just a small detail to be aware of.

Post a reply to this message

Am 27.04.2018 um 20:55 schrieb Sven Littkowski:
> Thanks. I was irritated, as in Photoshop the 256bit integers are no
> floats, but when simply multiplying, they are often enough still floats.
> I might have to round these numbers then, I guess. But that means losing
> exactness.

Such is the nature of 8-bit integers, as opposed to 32-bit floating
point numbers.

Post a reply to this message

Am 27.04.2018 um 21:41 schrieb dick balaska:

> I wouldn't worry about it. The human eye can't really tell the
> difference between RGB(121,85,198) and RGB(122,85,198).

That depends. If you place two uniform regions of those colours side by
side, the difference is quite obvious.

> (I never understood why the x87 uses 80 bit numbers internally, to
> minimize rounding error in calculations, but only allowed inputs and
> outputs of 64 bits. Why can't I have all those bits?)

As a matter of fact the x87 /does/ allow you to access all 80 bits. It's
up to the /compiler/ whether it supports storage of such values in main
memory. For example, in GCC the type seems to be available as
`__float80`, and back in the days in Turbo Pascal 6.0 the type was
available as `extended`.

One major reason why the type has fallen out of favour ages ago is that
ever since the first x86 CPU with a 32 bit wide data bus (80386-DX) or
the first x86 mainboard with a memory cache, it has been a pain to
manage its alignment: For optimal memory utilization consecutive float
elements should obviously be aligned to multiples of 80 bits, but for
optimal performance the alignment should be either an integer multiple
or an integer fraction of the data bus / cache line width, which only
works out for a width of 16 bits or less (presuming a power-of-2 width).

In modern software, virtually all fundamental data types to be stored in
memory have a power-of-2 width, for that very reason.

Post a reply to this message

On 04/27/2018 08:55 PM, Sven Littkowski wrote:
> Thanks. I was irritated, as in Photoshop the 256bit integers are no

    256bits ? What a fscking big CPU !!!

Post a reply to this message

Le 28/04/2018 à 18:41, tth a écrit :
> On 04/27/2018 08:55 PM, Sven Littkowski wrote:
>> Thanks. I was irritated, as in Photoshop the 256bit integers are no
> 
>    256bits ? What a fscking big CPU !!!
> 
> 
That's still too small for modern cryptography (and mining bitcoins).

Post a reply to this message