Thanks for the quick answer.

The concept of embedding three 8 bit components in one integer was clear to me, but I think that pd doesn't really use all 8 bits for the colors. Or maybe there is some issue with 2-complements or something.

For example, if I want to create three bang objects, in red (#ff0000), green (#00ff00) and blue (#0000ff), your formula gives values of: 16711680, 65280, 255 for the three colors.

But I insert them in a patch, like:

#N canvas 825 10 450 300 10; #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 16711680 0 0 ; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 65280 0 0 ; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 255 0 0 ;

I see the colors white, white, yellow.

Now, when I change the colors by hand, to really get red, blue and green on the bang objects and save the file, it reads:

#N canvas 825 10 450 300 10; #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -258049 -1 -1 ; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -4033 -1 -1 ; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -64 -1 -1 ;

So it uses negative numbers, and -64 means "full blue". Now, when I re-open the same file and look at the properties of the blue bang object, the color now reads: #0000fc instead of the #0000ff I entered just before saving.

That's why I suspect some lower resolution going on. I tried to browse this part in the sources, but all the GUI code confuses me.

For your interest, this patch results for colors of #040000, #000400 and #000004 set by hand in the properties window:

#X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -4097 -1 -1; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -65 -1 -1; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -2 -1 -1;

Setting colors to lower values, like #010000 results in getting them rounded down to #000000.

So, the resolution is apparently 256/4 = 64 values, or 6 bits.

Indeed, if I replace the formula with:

color = (-([red]+1)/4*64*64) - (([green]+1)/4*64) - ([blue]+1)/4

I get the same values that Pure Data produces. Hm, I might just have solved my problem.

It's still weird and some developer could check this our or change the documentation.

Cheers, Robert

On 02/13/2010 11:08 PM, Martin Peach wrote:

That formula should read: color = ([red] * 65536) + ([green] * 256) + ([blue]) In binary the idea is to shift the 8 'red' bits 16 to the left, then add 8 'green' bits shifted 8 bits, and finally 8 'blue' bits, so in all 24 bits are occupied. Multiplying the blue value by -1 in the original formula has the effect of setting the 16 bits to the left of it to 1, so you get different shades of pure blue.

Martin

Robert Schwarz wrote:

...

Hi all,

I recently tried writing patches in a text editor (or from scripts) and had problems getting the color settings right, for bang elements.

There is some documentation at http://puredata.info/docs/developer/fileformat with the explanation:

...

Color: Some graphical elements have color attributes. Per color only one signed integer value is stored that contains the three 8-bit color components (RGB). Formula to calculate color attribute values:

color = ( [red] * -65536) + ( [green] * -256) + ( [blue] * -1)

Where [red], [green], [blue] obviously represent the three color components, their values range from 0 to 255. They apply to the attributes [background color], [front color], [label color] of various elements.

I tried that, but it didn't work. Instead of showing the whole spectrum I just got different shades of blue. Also, when I opened one of my handwritten patches in PureData, looked at the color settings and saved, the resulting numbers changed. I assume that some kind of rounding is happening, and colors are actually saved in lower resolution.

Do you have any ideas?

Also, my application is a 13x13 button matrix, each triggering different chords via MIDI. The buttons should be color coded. Obviously, it's too much work setting all colors individually and I might want to create several of these patches with different colors. Maybe there is another obvious solution I didn't see.

Any help is appreciated!

(I'm using standard pd 0.42_5 on Arch Linux, but this shouldn't make a difference.)

I assume, this is because a 24bit integer cannot be saved with full precision with Pd, since Pd seems to strip off some bits when saving a floating point value (or when printing or displaying it). If the color would be encoded as RGB 8bpp, it would look different after saving and restoring it. So a smaller range had to be used.

When sending 'color' messages to the iemguis directly, the full 24bit resolution can be used.

Roman

On Sat, 2010-02-13 at 18:32 -0500, Martin Peach wrote:

Ah yes, in g_all_guis.c line 281:

void iemgui_all_colfromload(t_iemgui *iemgui, int *bflcol) { if(bflcol[0] < 0) { bflcol[0] = -1 - bflcol[0]; iemgui->x_bcol = ((bflcol[0] & 0x3f000) << 6)|((bflcol[0] & 0xfc0) << 4)| ((bflcol[0] & 0x3f) << 2); } else { bflcol[0] = iemgui_modulo_color(bflcol[0]); iemgui->x_bcol = iemgui_color_hex[bflcol[0]]; }

...so if the colour is negative it's a negated (all bits flipped) 18-bit rgb value and if it's positive it's an indexed colour from the iemgui palette. 111111RRRRRRGGGGGGBBBBBB is bit-flipped to get: 000000rrrrrrggggggbbbbbb which is shifted into this: rrrrrr00gggggg00bbbbbb00 so the 2 LSBs of each colour are set to 0. I don't know why.

Martin

Robert Schwarz wrote:

...

Thanks for the quick answer.

The concept of embedding three 8 bit components in one integer was clear to me, but I think that pd doesn't really use all 8 bits for the colors. Or maybe there is some issue with 2-complements or something.

For example, if I want to create three bang objects, in red (#ff0000), green (#00ff00) and blue (#0000ff), your formula gives values of: 16711680, 65280, 255 for the three colors.

But I insert them in a patch, like:

#N canvas 825 10 450 300 10; #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 16711680 0 0 ; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 65280 0 0 ; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 255 0 0 ;

I see the colors white, white, yellow.

Now, when I change the colors by hand, to really get red, blue and green on the bang objects and save the file, it reads:

#N canvas 825 10 450 300 10; #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -258049 -1 -1 ; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -4033 -1 -1 ; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -64 -1 -1 ;

So it uses negative numbers, and -64 means "full blue". Now, when I re-open the same file and look at the properties of the blue bang object, the color now reads: #0000fc instead of the #0000ff I entered just before saving.

That's why I suspect some lower resolution going on. I tried to browse this part in the sources, but all the GUI code confuses me.

For your interest, this patch results for colors of #040000, #000400 and #000004 set by hand in the properties window:

#X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -4097 -1 -1; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -65 -1 -1; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -2 -1 -1;

Setting colors to lower values, like #010000 results in getting them rounded down to #000000.

So, the resolution is apparently 256/4 = 64 values, or 6 bits.

Indeed, if I replace the formula with:

color = (-([red]+1)/4*64*64) - (([green]+1)/4*64) - ([blue]+1)/4

I get the same values that Pure Data produces. Hm, I might just have solved my problem.

It's still weird and some developer could check this our or change the documentation.

Cheers, Robert

On 02/13/2010 11:08 PM, Martin Peach wrote:

...

That formula should read: color = ([red] * 65536) + ([green] * 256) + ([blue]) In binary the idea is to shift the 8 'red' bits 16 to the left, then add 8 'green' bits shifted 8 bits, and finally 8 'blue' bits, so in all 24 bits are occupied. Multiplying the blue value by -1 in the original formula has the effect of setting the 16 bits to the left of it to 1, so you get different shades of pure blue.

Martin

Robert Schwarz wrote:

...

Hi all,

I recently tried writing patches in a text editor (or from scripts) and had problems getting the color settings right, for bang elements.

There is some documentation at http://puredata.info/docs/developer/fileformat with the explanation:

...

Color: Some graphical elements have color attributes. Per color only one signed integer value is stored that contains the three 8-bit color components (RGB). Formula to calculate color attribute values:

color = ( [red] * -65536) + ( [green] * -256) + ( [blue] * -1)

Where [red], [green], [blue] obviously represent the three color components, their values range from 0 to 255. They apply to the attributes [background color], [front color], [label color] of various elements.

I tried that, but it didn't work. Instead of showing the whole spectrum I just got different shades of blue. Also, when I opened one of my handwritten patches in PureData, looked at the color settings and saved, the resulting numbers changed. I assume that some kind of rounding is happening, and colors are actually saved in lower resolution.

Do you have any ideas?

Also, my application is a 13x13 button matrix, each triggering different chords via MIDI. The buttons should be color coded. Obviously, it's too much work setting all colors individually and I might want to create several of these patches with different colors. Maybe there is another obvious solution I didn't see.

Any help is appreciated!

(I'm using standard pd 0.42_5 on Arch Linux, but this shouldn't make a difference.)

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

Yes but why? You can accurately represent every 32-bit int with a float, but Pd clips them by using the %g format specifier to print them, instead of %f.

In m_atom.c, at line 68, the function atom_string() converts atoms into strings, and in the case of float atoms, uses this line to do it:

sprintf(tbuf, "%g", a->a_w.w_float);

This prints both of the floats 16777215.0 and 16777214.0 as "167772e+7". It seems to me that

sprintf(tbuf, "%f", a->a_w.w_float);

would be better, since it prints 16777215.000000, 16777214.000000.

Martin

Roman Haefeli wrote:

I assume, this is because a 24bit integer cannot be saved with full precision with Pd, since Pd seems to strip off some bits when saving a floating point value (or when printing or displaying it). If the color would be encoded as RGB 8bpp, it would look different after saving and restoring it. So a smaller range had to be used.

When sending 'color' messages to the iemguis directly, the full 24bit resolution can be used.

Roman

On Sat, 2010-02-13 at 18:32 -0500, Martin Peach wrote:

...

Ah yes, in g_all_guis.c line 281:

void iemgui_all_colfromload(t_iemgui *iemgui, int *bflcol) { if(bflcol[0] < 0) { bflcol[0] = -1 - bflcol[0]; iemgui->x_bcol = ((bflcol[0] & 0x3f000) << 6)|((bflcol[0] & 0xfc0) << 4)| ((bflcol[0] & 0x3f) << 2); } else { bflcol[0] = iemgui_modulo_color(bflcol[0]); iemgui->x_bcol = iemgui_color_hex[bflcol[0]]; }

...so if the colour is negative it's a negated (all bits flipped) 18-bit rgb value and if it's positive it's an indexed colour from the iemgui palette. 111111RRRRRRGGGGGGBBBBBB is bit-flipped to get: 000000rrrrrrggggggbbbbbb which is shifted into this: rrrrrr00gggggg00bbbbbb00 so the 2 LSBs of each colour are set to 0. I don't know why.

Martin

Robert Schwarz wrote:

...

Thanks for the quick answer.

The concept of embedding three 8 bit components in one integer was clear to me, but I think that pd doesn't really use all 8 bits for the colors. Or maybe there is some issue with 2-complements or something.

For example, if I want to create three bang objects, in red (#ff0000), green (#00ff00) and blue (#0000ff), your formula gives values of: 16711680, 65280, 255 for the three colors.

But I insert them in a patch, like:

#N canvas 825 10 450 300 10; #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 16711680 0 0 ; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 65280 0 0 ; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 255 0 0 ;

I see the colors white, white, yellow.

Now, when I change the colors by hand, to really get red, blue and green on the bang objects and save the file, it reads:

#N canvas 825 10 450 300 10; #X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -258049 -1 -1 ; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -4033 -1 -1 ; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -64 -1 -1 ;

So it uses negative numbers, and -64 means "full blue". Now, when I re-open the same file and look at the properties of the blue bang object, the color now reads: #0000fc instead of the #0000ff I entered just before saving.

That's why I suspect some lower resolution going on. I tried to browse this part in the sources, but all the GUI code confuses me.

For your interest, this patch results for colors of #040000, #000400 and #000004 set by hand in the properties window:

#X obj 0 0 bng 15 200 50 0 target empty empty 0 0 0 8 -4097 -1 -1; #X obj 0 15 bng 15 200 50 0 target empty empty 0 0 0 8 -65 -1 -1; #X obj 0 30 bng 15 200 50 0 target empty empty 0 0 0 8 -2 -1 -1;

Setting colors to lower values, like #010000 results in getting them rounded down to #000000.

So, the resolution is apparently 256/4 = 64 values, or 6 bits.

Indeed, if I replace the formula with:

color = (-([red]+1)/4*64*64) - (([green]+1)/4*64) - ([blue]+1)/4

I get the same values that Pure Data produces. Hm, I might just have solved my problem.

It's still weird and some developer could check this our or change the documentation.

Cheers, Robert

On 02/13/2010 11:08 PM, Martin Peach wrote:

...

That formula should read: color = ([red] * 65536) + ([green] * 256) + ([blue]) In binary the idea is to shift the 8 'red' bits 16 to the left, then add 8 'green' bits shifted 8 bits, and finally 8 'blue' bits, so in all 24 bits are occupied. Multiplying the blue value by -1 in the original formula has the effect of setting the 16 bits to the left of it to 1, so you get different shades of pure blue.

Martin

Robert Schwarz wrote:

...

Hi all,

I recently tried writing patches in a text editor (or from scripts) and had problems getting the color settings right, for bang elements.

There is some documentation at http://puredata.info/docs/developer/fileformat with the explanation:

...

Color: Some graphical elements have color attributes. Per color only one signed integer value is stored that contains the three 8-bit color components (RGB). Formula to calculate color attribute values:

color = ( [red] * -65536) + ( [green] * -256) + ( [blue] * -1)

Where [red], [green], [blue] obviously represent the three color components, their values range from 0 to 255. They apply to the attributes [background color], [front color], [label color] of various elements.

I tried that, but it didn't work. Instead of showing the whole spectrum I just got different shades of blue. Also, when I opened one of my handwritten patches in PureData, looked at the color settings and saved, the resulting numbers changed. I assume that some kind of rounding is happening, and colors are actually saved in lower resolution.

Do you have any ideas?

Also, my application is a 13x13 button matrix, each triggering different chords via MIDI. The buttons should be color coded. Obviously, it's too much work setting all colors individually and I might want to create several of these patches with different colors. Maybe there is another obvious solution I didn't see.

Any help is appreciated!

(I'm using standard pd 0.42_5 on Arch Linux, but this shouldn't make a difference.)

---

Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev