[PD] data structures - color?

[Mathieu Bouchard]

On Sat, 25 Mar 2006, IOhannes m zmoelnig wrote:

>> In GF it would be difficult if using the default int types à la GEM. 
>> However, unlike GEM and PDP, GF also supports float images, so if you 
>> really want to use float colors in GF, you can do it.
> where do you see any difficulties?

Ok, this is a really old mail, but it's worth replying to anyway.

> the question is how the colours are represented in "pd number space" 
> (this is: the numbers you see in numberboxes). Gem uses internally 
> "unsigned char" to represent numbers, pdp uses "short" and GF uses 
> various types. however, when you set a colour in Gem, you say "1.f 0.f 
> 0.f" and not "0xff 0xff 0xff"; the user need not know about how the 
> numbers are handled internally

In GridFlow, when dealing with int pictures, you are stuck with 
considering pixels as ints, though in whichever range you want. When you 
deal with float images however, you can use the range 0..1 in 1073741824 
shades of grey, and even more in float64 (when float64 really works...).

I didn't do like Jitter in which the type confusingly named "char" is 
actually a 0,8 fixed point, that is, that has all fractions with 
denominator 256 and numerators from 0 to 255.

That info about GridFlow applies to all versions of GridFlow since early 
2003.

> i think hc's idea is (and i very much like it), that you could also set 
> the iemgui's colours with something like "1.f 0.f 0.f"

Almost. Don't use the trailing f because else Pd will think of it as a 
symbol; also, the period is optional because there are no int atoms in Pd.

> instead of "0.9e7" (or whatever, i haven't checked).

Any representation that ends up looking like that is garbled, because 
IEMGUI colours assume that they have a contiguous integer range. When Pd 
uses such a representation, it drops a few digits at the same time, enough 
to blow up the value of one channel. That's why in addition to the 24-bit 
representation, IEMGUI also uses a 18-bit representation (When Pd converts 
integer floats to decimal, it can only preserve int20 or uint19). (I don't 
really know why IEMGUI doesn't just use 18-bit but also 24-bit.)

The number -262144, which you often see in patches, is -2^18.

> though i would be far better (in terms of readability and colour-depth) 
> if the colours would be saved with something like "#ff00ff" - using 
> symbols to circumvent pd's rounding errors

In the .ddrc we use #rrggbb values, but for the #V attributes I haven't 
decided yet. I'm seriously thinking of using three ints from 0 to 255, 
e.g.:

#X obj 42 42 dac~;
#V bg 255 85 0 \, fg 255 255 0;

When you wrote the mail I'm replying to, I hadn't decided on whether #V 
attributes could be multiple-values or not. Now I've decided, so I'm 
confident in suggesting the above solution. What's bad is that I'd rather 
"replace" the old formats by only one instead of two.

(But of course, for compatibility reasons I can't get rid of old formats, 
so I have to use at least 6 color formats at once.)

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada