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 <[email protected]> > Subject: Re: [PD-dev] pd file format: color settings > To: [email protected] > Cc: Martin Peach <[email protected]>, [email protected] > Message-ID: <[email protected]> > 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 >>> [email protected] >>> http://lists.puredata.info/listinfo/pd-dev >> >> >> >> _______________________________________________ >> Pd-dev mailing list >> [email protected] >> 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 _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
