[PD-dev] pd file format: color settings

[Martin Peach]

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.)
>>>
>