[PD-dev] pd file format: color settings

Patrick Boivin pboivin at gmail.com
Tue Feb 16 01:51:34 CET 2010


Hi,

there's also [#to_iem] in gridflow 0.9.7 (svn) that does rgb to iemgui
color conversion.


> Date: Sun, 14 Feb 2010 12:26:51 -0500
> From: Hans-Christoph Steiner <hans at at.or.at>
> Subject: Re: [PD-dev] pd file format: color settings
> To: reduzierer at yahoo.de
> Cc: Martin Peach <martin.peach at sympatico.ca>, pd-dev at iem.at
> Message-ID: <425FDA03-43CB-40C8-8F0E-68E55236E13D at at.or.at>
> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed;
>        delsp=yes
>
>
> Also, there are some conversion objects around, I think in pdmtl for
> example.
>
> .hc
>
> On Feb 14, 2010, at 12:15 PM, 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 at iem.at
>>> http://lists.puredata.info/listinfo/pd-dev
>>
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> 'You people have such restrictive dress for women,? she said, hobbling
> away in three inch heels and panty hose to finish out another pink-
> collar temp pool day.  - ?Hijab Scene #2", by Mohja Kahf




More information about the Pd-dev mailing list