hi,

I really dont understand the canvas colors message schema

I mean how do I use regular rgb in messages to set the color of a canvas ?

thanks

@Jojo-Lapin tell me about it

...

R is 204 / G is 153 / B is 204

i = B + (G * 256) + (R * 256 * 256)
i = 204 + (153 * 256) + (204 * 256 * 256)

color = -1 -i
color = -1 -13408716

color is -13408717

@Jojo-Lapin It is pretty simple really...... its just that computers prefer hex......
David.

You need to pack 3 integers in a unique float (cross your fingers and later scratch your head to think about floating point precision) with bitwise operations and then negate it (instead of ((("- Why?"))) just provide those three arguments). And later that number is altered just by saving it to a file. It is NOT simple.

@Jojo-Lapin well so far I am lucky I dont need to save these values

I think perhaps one of the problems expressed here (though I'm not sure which one!) has to do with the dual-precision internal processing vs. single-precision external save/retrieve limitation present in all versions of Pd, with the exception (I assume, haven't tried it yet) of the experimental dual-precision build that was produced some time ago.

I unexpectedly ran into the issue myself when trying to set up dynamic color programming of the GUI objects after making a whole panel of them using the preset colors from the preferences panel. I noticed immediately that most of the 0-29 preset color numbers that I sent with messages obviously didn't quite match the 30 presets available in the panel grid. So I tried grabbing the RGB values instead by plugging them into the "pd RGB" calculator that's part of the GUI color edit help patch. Those wouldn't save properly. I must assume at this point that it's because those panel colors are all linked internally in Pd to the 6 digit hex value you can see in the "compose color" RGB pop-up panel. Many of those hex values translate to dual-precision decimal numbers, (which can't be saved without the app rounding them off) and on the external user-programmable level Pd only works with decimals, not hex.

What it comes down to is that although you can enter or generate dual-precision decimal values in realtime (like with "pd RGB"). You can't save/retrieve them without the numbers getting rounded.

My workaround to match the panel presets was to just fudge the single-precision decimals till I got it "close enough". The only other workaround I can think of to get it exactly right is to save the three RGB numbers as a list and then feed them with [unpack] to the pd RGB calc and embed the whole blob into the patch every time I wanted to switch some colors.

The various Pd sites and lists have a number of write-ups about the dual/single precision issues. There's also some stuff on the list somewhere about the 2 different sets of preset colors (I think the remote-switchable preset values all translate to single precision dec values, not sure). Don't have any links on hand ATM but the info can be found in many bits and pieces (like most of the info on this platform) if anyone is more interested in this topic.

I found the post i read recently about the color scheme on the Pd-dev list.

< https://lists.puredata.info/pipermail/pd-dev/2016-01/020535.html >

@Jojo-Lapin Thanks, that link sums it up rather well.

Edit: Upon re-reading that link, It would seem that even the extended dec values don't represent the true 24-bit colors but are a "crunched" format to try to get as close as they could with the single-precision limitations. No wonder nobody understands it!

To save the iem colors two bits of each component are scratched.

RRRRRRRRGGGGGGGGBBBBBBBB
RRRRRR__GGGGGG__BBBBBB__
RRRRRRGGGGGGBBBBBB

The 8 bits per component is compressed to 6 bits per component. It is expanded at load in the opposite side.

You lose 2 bits of precision (i.e 255 becomes 252)

@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)) ]