Searched the forums on all kinds of variations of the search terms KdColor and RGB and convert going back 500 days and didn't find any reference.

Looking for a script or app (my cpu is bi-polar, intelMac so I can run either OSX or Win app) that if you feed it KdColor's you get the RGB equivalent or even the reverse.

for example RGB 188, 13, 0 = KdColor 0.745098 0.0509804 0

But I did that the hard way of creating the target color in CS2 writing down the RGB values. Going into the material room and using the RGB sliders and entering those values. Then saving to the material room and then getting the KdColor values. 

thanks in advance for anyone who can help in this search

Attached Link: http://ockhamsbungalow.com/Python/RGB-KD.ZIP

If it seems to work, I could add clipboard copy-paste actions.....

Cool thanks a ton. You seem to have created a ton of valuable scritps that save people so much time and perform great functions.

Curious, have you made one called "Make Art" yet (snicker)

Again thank you very much.

I just revised this slightly.   If you DL'd it more than a minute ago, DL again!

(The math was off by a little.)

I did a rather cute Make Art for April Fools a few years ago. 

It's probably lost in cyberspace, though.

Quote - Here's a quickie. 

If it seems to work, I could add clipboard copy-paste actions.....

If you keep this up I'll have to make a 3rd  sub button in my python window for you.  I already have 2 sub buttons with your scripts; one  with 7 scripts and the other with 4, hehe

Hmm the first one didn't do this. Have no idea what these values are just picked them at random. But enter 188 200 125 and to KD then back to RGB and the 125 becomes 124. I assume it is a rounding error. But I thought I would report it back. I owe you that much for supplying it, if not more.

I know one digit is not a lot and is just fine for what I am doing whcih is creating and then just editing or altering-duplicating a master of bunch of shaders to use as finger  and toe nail colors. It is far easier  and way faster for me to go into PS CS2 and mess with colors there and shades and use this script and then just edit duplicated material files. This makes that job a ton easier and quicker.

again thanks a ton.

FYI I am on an Intel Mac. So I have no idea if my OS has any part of the math rounding vs say a winTel box.

Yeah, I noticed the same thing with the rounding.  I'll see how the conversion
is handled by Poser's internal codes and make the units agree with those.  

Mac and Win should agree on this; it's not a deep CPU thing.
 

All that should be happening in one direction is:

r = n/255 where n is in RGB (integer) to go to a real value between 0.0 and 1.0 (so 0 = 0.0 and 255 = 1.0)

and, obviously, in the other direction:

n = r * 255 where r is the real value between 0.0 and 1.0 and n is between 0 and 255.

It may be that they are not rounding properly.  The default behaviour for n = r * 255 is to truncate when converting a real value to an integer.  So, even 19.99999 = 19 in this scenario.  The proper way to do it like this is to take the decimal part and add 1 to n if the decimal part is greater than or equal to 0.5.

float m = r * 255;
int n = (int)n;
float r = (float)(m - n);
if (r >= 0.5) ++n;

It's not as much a 'deep CPU thing' as an implementation thing with conversion.  Standard methodologies are clear on rounding procedures when going from floating point to integer approximations or equivalents.

Rounding is better now, and also took care of some odd things
that happened with zero entries.  Same link, new content....
be sure your browser isn't caching the old one!

While that's the correct rounding method, it can also be implemented by adding 0.5 and truncating. 2.4 + 0.5 = 2.9 truncates to 2 2.6 + 0.5 = 3.1 truncates to 3 Though I think there have been changes within Poser that altered what happens to an exact .5 value in some of the shader math functions.

That's true.  A bit late and did it the long way. :)

Maybe precision is an issue here.  If the value is seen as .49999..., when it really is .5 that might tip the balance for the lower truncation.

I'm not au fait with the internal represenation of floating point, but it is binary, isn't it? So 0.5 is a determinable binary value. I know Poser occasionally stores 0.499999 instead od 0.500000

Of course any base computer representation is binary.  But there are differing type representations (EBIDIC, ASCII, ANSI, Unicode for text characters for instance).  Floating point values are usually stored in IEEE Sign-Exponent-Mantissa representation.  In the CPU they are usually stored as double (or maybe long-double 64-bit these days).  When the value is demoted to a shorter representation (such as long-double to double or double to float), a certain amount of precision is lost in the process.  This is just the nature of binary digital representations.

Basically, the more math you do on a floating point 'value', the more loss of precision creeps in.  This occurs no matter what you do.  The best algorithms are designed with an error consideration and may either minimize it or 'rectify' it when possible.

So, there are roundoff errors and truncation errors which can creep into even seemingly stable floating point values over time if not checked and considered.