@Jojo-Lapin Yeah I tend to agree, unless they start making a dual-precision build as the new standard.
I was just dealing with trying to recreate panel preset color 8 as the remote message preset was a bit too light. The 196 196 252 RGB value becomes 196 196 8 with the dec value from pd RGB. Arrrgghhh......

Too light it stays.

Strange with vanilla 0.46.7 and the [color -12895485( message i set the value properly (at least on a bng object).
In your case the difference seems too big to result only from a floating-point issue, isn't it?

@Jojo-Lapin It has ABSOLUTELY nothing to do with Pure Data...... and quite a lot to do with everything else..... especially x11, win32, the real world.......... etc. Everyone seems to be forgetting that they run Pure Data on (many different) pieces of hardware under (many different) operating systems and display colors on (many different) monitors and under (many different) browsers..........
I doubt that a human could tell the difference anyway (maybe except for shades of green)......
https://en.wikipedia.org/wiki/Web_colors#Safest_web_colors
and especially......
http://www.december.com/html/spec/colorsafe.html
David.

@Jojo-Lapin I did some more checking, and I agree something else is coming into play here. Try the patch below and see if you notice a discrepancy between the static color messages vs. the dynamically packed singe number messages from the contraption I derived from the color selection help patch.

Whale-av's comment does have some relevance to this in that the differences I was seeing between the panel and remote message presets can be more or less noticeable depending on the monitor, but what I'm getting on this end with the same numbers generated and sent in a different manner is pretty extreme, both in what I can see on the screen and the actually RGB numbers that are produced on the other end.

GUI_color_select_bug.pd

A little bit with the modified patch uploaded below.

toto.pd

@Jojo-Lapin Hmmm... Yes I can see you used a different decimal value (perhaps [pd RGB] is messing things up) but there's still something weird going on. I'm on Linux ATM BTW. Things do look different when I run my patches on the mac but when I run the same patches on both machines w/the same monitor I'm running the mac thru DVI and the linux box thru VGA so I can never tell for sure.

Also -- in the past when I've tried to save a message with a value that gets rounded, I've always seen the rounded value in the message after retrieving it. Don't know if anything has changed with the newer versions of Pd I've been using lately (46-6 and 46-7). All the numbers and messages look consistent when I send them through a print object to the console (if that's really telling me anything) but I still get a different result on the other end.

Anyway thanks for checking that...

Managing color precisely is hard.
Few time ago i worked on a PDF renderer that used the ICC profiles.
That's not very fun.
Don't do it if you don't really need it.
In that case it is not easy to guess if it is due to the hardware or to Pd itself.

(( Oops sorry if forget that "It has ABSOLUTELY nothing to do with Pure Data." )).

@Jojo-Lapin Hello JoJo........ I am sorry that I was so "ratty" in that post...........
I am pleased that you have managed to get where you want to be with the colors (after a lot of hard work)........
But that is the point that I was trying to make....... it is a compromise forced by the environment.
If you passed me your perfected tcl it would not work in the same way in my environment.
And that Pd was not built as a free alternative to Photoshop.......
David.

I guess the essential question that's bugging me about this is that regardless of what colors I'm seeing on whatever monitor I'm using connected to whatever computer, OS and Pd version I'm using -- why are the actual numbers that represent those colors just coming up wrong on the receiving end when I send them one way versus another?

Not that I expect an answer, that's just what I'm thinking.

Off topic: I once worked out the RGB equivalents of the 30 preset colours that PD uses ("color 1", "color 2", etc). Still suffers from the same lack of precision you're talking about, but maybe it will be useful to somebody.
colour_presets.pd

@NoDSP nop my issue was just "set the color" related, not save/load

an the answer was expr [ -1-(B + (G * 256) + (R * 65536)) ]

@NoDSP pd\doc\manuals\MessageOddness\float-precision-misrepresentation.pd
Maybe?
David.

no such file on my windows pd v 0.46-7

@phil123456 odd.zip (extended) ......... maybe fixed? in latest vanilla....
David.

@whale-av thx

Try using this one, All input values 0-255

connect it to a message like
|;__________________/
|yourcanvas color $1\

RGB.pd

@Guest after reading this article i now know why when i save 255 as a value to any color in rgb in e.g. canvases, it will make it 252 when saving and rebooting pd.

Not sure if I should even bother sharing this thread started to get over my head real quick when the rgb tcl talk started. This process does not use rgb messages.

But originally thought i had some things to share so i spent a few minutes writing this so im going to share it anyways. LMAO

This patch will update the canvas color when a index for the canvas is given.

CanvasRealTimeColorChange.pd

I should mention I have this setup to be used for multiple items. This is how i am using the patch. i have a [bng] underneath a canvas to keep it hidden we will call this my "songitem" This will make the canvas act as a [bng] just make sure the [bng] has the same dimensions as the canvas. So when a [bng] is pressed the canvas color will change to the active color. Then when any other button is pressed it will then become the "active" color and the previous canvas will return to the "default" color.

So if you had a canvas with the send and recieve symbols set as $1-Canvas-send $1-Canvas-recv you can easily feed the index of the canvas by replacing {r selsongitem}
with a inlet and feed whatever index you desired.

Its usage is highlighted in the screenshot.

Near the bottom of the patch you will find the object [symbol $1-songitem-recv]
change $1-songitem-recv to the proper recv symbol for your canvas.

If anything I hope this patch sparks some ideas for new people to pd. I'm only a year in and I think I'm developing a bald spot. lol i kid. And for the vets please pick this apart i need to learn what to do and what not to Ive been focusing on the order of operations as of late.

Enjoy

@RetroMaximus I would consider the use of delay to get the order of operations right a mistake and this should in almost all cases be solvable by using trigger.

Here is a simple radio button set using canvases to hide the bangs: canvasradio.pd

@ingox Gosh you make it looks so easy. lol Thx once again