I just made a patch to see which colors are available in the data
structures. it seems that they're not the same as in the normal pd scheme,
and that they repeat themselves. is it normal that colors 0 == 100 == 200
== 300, 400 == 500 and 600 == 700?
wouldn't it be useful for all color schemes to be synchronised?
João
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
I just made a patch to see which colors are available in the data
structures. it seems that they're not the same as in the normal pd scheme,
and that they repeat themselves. is it normal that colors 0 == 100 == 200
== 300, 400 == 500 and 600 == 700?
By definition these are not the same, though they really look like it and they show the same rgb-values when captured and tested in the Gimp. Strange.
wouldn't it be useful for all color schemes to be synchronised?
Surely, however as it currently is, we have at least 3 color schemes in Pd and Gem: IEM colors, which nobody really understands, Gem colors, which are lists of R G B values with R G and B going from 0 to 1, and data structure colors which are similar to Gem colors, but R G and B go from 0 to 9 instead of from 0 to 1 and they can only be integers and they are not lists but concatenated numbers.
So: Black Gem: 0 0 0 Black DS: 000 Red Gem: 1 0 0 Red DS: 900 (^= "9 * 1 0 0") White Gem: 1 1 1 White DS: 999 (^= "9 * 1 1 1")
etc.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On the other hand, I noticed that the '999=white' color scheme (used for data) wasn't working very well, and have tried to improve it for the next version...
cheers Miller
On Fri, Mar 24, 2006 at 01:49:42AM +0100, Frank Barknecht wrote:
Hallo, Jo?o Miguel Pais hat gesagt: // Jo?o Miguel Pais wrote:
I just made a patch to see which colors are available in the data
structures. it seems that they're not the same as in the normal pd scheme,
and that they repeat themselves. is it normal that colors 0 == 100 == 200
== 300, 400 == 500 and 600 == 700?By definition these are not the same, though they really look like it and they show the same rgb-values when captured and tested in the Gimp. Strange.
wouldn't it be useful for all color schemes to be synchronised?
Surely, however as it currently is, we have at least 3 color schemes in Pd and Gem: IEM colors, which nobody really understands, Gem colors, which are lists of R G B values with R G and B going from 0 to 1, and data structure colors which are similar to Gem colors, but R G and B go from 0 to 9 instead of from 0 to 1 and they can only be integers and they are not lists but concatenated numbers.
So: Black Gem: 0 0 0 Black DS: 000 Red Gem: 1 0 0 Red DS: 900 (^= "9 * 1 0 0") White Gem: 1 1 1 White DS: 999 (^= "9 * 1 1 1")
etc.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Mar 23, 2006, at 7:49 PM, Frank Barknecht wrote:
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
I just made a patch to see which colors are available in the data structures. it seems that they're not the same as in the normal pd
scheme, and that they repeat themselves. is it normal that colors 0 == 100
== 200 == 300, 400 == 500 and 600 == 700?By definition these are not the same, though they really look like it and they show the same rgb-values when captured and tested in the Gimp. Strange.
wouldn't it be useful for all color schemes to be synchronised?
Surely, however as it currently is, we have at least 3 color schemes in Pd and Gem: IEM colors, which nobody really understands, Gem colors, which are lists of R G B values with R G and B going from 0 to 1, and data structure colors which are similar to Gem colors, but R G and B go from 0 to 9 instead of from 0 to 1 and they can only be integers and they are not lists but concatenated numbers.
So: Black Gem: 0 0 0 Black DS: 000 Red Gem: 1 0 0 Red DS: 900 (^= "9 * 1 0 0") White Gem: 1 1 1 White DS: 999 (^= "9 * 1 1 1")
The whole color thing is a bit of a mess. I think that the Gem float
RGB scheme should be adopted everywhere. In fact, I think that since
Pd is all about floats, we should make the default range 0-1 for
everything unless there is a really good reason to do otherwise.
This includes sliders, GUIs like [grid], [gcanvas], [knob], colors,
etc. (things related to audio signals often need -1 to 1, but its
basically the same idea).
In the process of writing the mapping lib with Cyrille, I have really
seen the power of using the same data range. It allows you to do
things on a logic level without having to think about math. But math
is still an option. FYI: the mapping lib objects all accept 0-1 and
output 0-1. Even things like angles are outputted 0-1 instead of -pi
to pi or 0-360.
.hc
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
In the process of writing the mapping lib with Cyrille, I have really
seen the power of using the same data range. It allows you to do
things on a logic level without having to think about math. But math
is still an option. FYI: the mapping lib objects all accept 0-1 and
output 0-1. Even things like angles are outputted 0-1 instead of -pi
to pi or 0-360.
Which leaves open, if 0-1 should be expected to be -pi to pi or 0 to 360! ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, 23 Mar 2006, Hans-Christoph Steiner wrote:
The whole color thing is a bit of a mess. I think that the Gem float RGB scheme should be adopted everywhere.
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.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mar 25, 2006, at 2:22 AM, Mathieu Bouchard 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.
...GEM also supports floating point images via [gemframebuffer]
(currently only creates floating point render buffers, but will soon
have selectable colorspace's) and arb_program/glsl_shaders...
jamie
Mathieu Bouchard wrote:
On Thu, 23 Mar 2006, Hans-Christoph Steiner wrote:
The whole color thing is a bit of a mess. I think that the Gem float RGB scheme should be adopted everywhere.
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? 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 (sometimes they will have to, e.g. when it comes to rounding errors)
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" instead of "0.9e7" (or whatever, i haven't checked). it is not really important if the the colour-representation in the saved patch is again some magic word (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)
mfg.as.d IOhannes
On Mar 25, 2006, at 4:39 PM, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
On Thu, 23 Mar 2006, Hans-Christoph Steiner wrote:
The whole color thing is a bit of a mess. I think that the Gem
float RGB scheme should be adopted everywhere.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? 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 (sometimes they will have to, e.g. when it comes to rounding errors)
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" instead of "0.9e7" (or whatever, i haven't checked). it is not really
important if the the colour-representation in the saved patch is again some magic word (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)
I think floats would be simplest, tho there would be three atoms in
place of one. If you use one Pd float for each R, G, and B, I don't
think rounding errors would be an issue, unless you are doing really
high bitdepth color. Standard formats are 8-bit per color, Pd can do
19-bit integers (almost 20-bit).
But of course, that probably makes thing more complicated to change...
.hc
"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it."
- Thomas
Jefferson
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think floats would be simplest, tho there would be three atoms in
place of one.
Which is a problem, because a one-element specification for colors is needed as well (e.g. to pass colors as abstraction arguments, in data structures etc.)
Personally I like hex colors, but I'm used to them from web work.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mar 26, 2006, at 2:42 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think floats would be simplest, tho there would be three atoms in place of one.
Which is a problem, because a one-element specification for colors is needed as well (e.g. to pass colors as abstraction arguments, in data structures etc.)
What makes this requirement one element for color? Changing the
format will break backwards compatibility anyway, so you could change
one to three elements. I think 3 floats would make things much
easier to use, like [colorRGB].
Personally I like hex colors, but I'm used to them from web work.
If it must be one element, then hex colors would be the way.
.hc
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers.
- General Smedley Butler
The reason to use a single number as a color was because 3-component colors in a data structure drawing command just seemed too unwieldly. But I'm starting to wonder if this was truly a wise decision to make. The trouble now is it would mean having two versions of every drawing instruction, yuck!
M
On Sun, Mar 26, 2006 at 09:48:07AM -0500, Hans-Christoph Steiner wrote:
On Mar 26, 2006, at 2:42 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think floats would be simplest, tho there would be three atoms in place of one.
Which is a problem, because a one-element specification for colors is needed as well (e.g. to pass colors as abstraction arguments, in data structures etc.)
What makes this requirement one element for color? Changing the
format will break backwards compatibility anyway, so you could change
one to three elements. I think 3 floats would make things much
easier to use, like [colorRGB].Personally I like hex colors, but I'm used to them from web work.
If it must be one element, then hex colors would be the way.
.hc
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General Smedley Butler
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You could probably make one function be a wrapper to the other, which
wouldn't be so bad...
It would be really nice to have one color format throughout Pd, when
its GUI objects, data structures, Gem, PDP, etc. 0-1 for R,G,B seems
to be a natural for Pd. It would also have the added benefit of
making patches with color work the same no matter what the color
depth (e.g. 0.5,0.5,0.5 would always be middle grey, whether on 4-
bit, 8-bit, 16-bit, or 24-bit).
.hc
On Mar 28, 2006, at 8:04 PM, Miller Puckette wrote:
The reason to use a single number as a color was because 3-component colors in a data structure drawing command just seemed too unwieldly. But I'm starting to wonder if this was truly a wise decision to make. The trouble now is it would mean having two versions of every drawing instruction, yuck!
M
On Sun, Mar 26, 2006 at 09:48:07AM -0500, Hans-Christoph Steiner
wrote:On Mar 26, 2006, at 2:42 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I think floats would be simplest, tho there would be three atoms in place of one.
Which is a problem, because a one-element specification for
colors is needed as well (e.g. to pass colors as abstraction arguments, in
data structures etc.)What makes this requirement one element for color? Changing the format will break backwards compatibility anyway, so you could change one to three elements. I think 3 floats would make things much easier to use, like [colorRGB].
Personally I like hex colors, but I'm used to them from web work.
If it must be one element, then hex colors would be the way.
.hc
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"The arc of history bends towards justice."
- Dr. Martin Luther King,
Jr.
The reason to use a single number as a color was because 3-component colors in a data structure drawing command just seemed too unwieldly. But I'm starting to wonder if this was truly a wise decision to make. The trouble now is it would mean having two versions of every drawing instruction, yuck!
yeah, but once all formats are equally compatible, then in no time they
would be used by all (I think, it sound logical). of couse back-comp would
be nice...
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
The reason to use a single number as a color was because 3-component colors in a data structure drawing command just seemed too unwieldly. But I'm starting to wonder if this was truly a wise decision to make. The trouble now is it would mean having two versions of every drawing instruction, yuck!
yeah, but once all formats are equally compatible, then in no time they
would be used by all (I think, it sound logical). of couse back-comp would
be nice...
Personally I think, 1-element colors are easier to handle, especially as we don't have [pak] yet. In an abstraction, I would only need to use one dollar variable to pass a color instead of three, and the required counting of positional arguments in data structure drawing instructions already is *very errorprone*. And using 3-element colors would triple the amount of color arguments to count! I'm already trembling ...
My GEM patches OTOH have a lot of [unpack $1 $2 $3] constructs. Btw: It would be nice if the GEM color objects would accept lists instead of being forced to [unpack 0 0 0] in front of every colorRGB object.
But I admit: Generally colors don't map well to a one-dimensional scale, as the data structure colors show. Colors generally are better mapped to things like a 2-dimensional color circle or to three or four sliders. Encoding RGB color in one float is hard enough, but how to encode RGBA into one float?
This really is a hard question and probably it is another area, where a general mapping abstraction library will be necessary.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Zitat von Frank Barknecht fbar@footils.org:
My GEM patches OTOH have a lot of [unpack $1 $2 $3] constructs. Btw: It would be nice if the GEM color objects would accept lists instead of being forced to [unpack 0 0 0] in front of every colorRGB object.
that's why there is the [color] object which accepts lists.
mfga.sdr# IOhannes
Hallo, zmoelnig@iem.at hat gesagt: // zmoelnig@iem.at wrote:
Zitat von Frank Barknecht fbar@footils.org:
My GEM patches OTOH have a lot of [unpack $1 $2 $3] constructs. Btw: It would be nice if the GEM color objects would accept lists instead of being forced to [unpack 0 0 0] in front of every colorRGB object.
that's why there is the [color] object which accepts lists.
Argh.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mar 29, 2006, at 10:38 AM, Frank Barknecht wrote:
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
The reason to use a single number as a color was because 3-component colors in a data structure drawing command just seemed too
unwieldly. But I'm starting to wonder if this was truly a wise decision to
make. The trouble now is it would mean having two versions of every
drawing instruction, yuck!yeah, but once all formats are equally compatible, then in no time
they would be used by all (I think, it sound logical). of couse back- comp would be nice...Personally I think, 1-element colors are easier to handle, especially as we don't have [pak] yet. In an abstraction, I would only need to use one dollar variable to pass a color instead of three, and the required counting of positional arguments in data structure drawing instructions already is *very errorprone*. And using 3-element colors would triple the amount of color arguments to count! I'm already trembling ...
My GEM patches OTOH have a lot of [unpack $1 $2 $3] constructs. Btw: It would be nice if the GEM color objects would accept lists instead of being forced to [unpack 0 0 0] in front of every colorRGB object.
But I admit: Generally colors don't map well to a one-dimensional scale, as the data structure colors show. Colors generally are better mapped to things like a 2-dimensional color circle or to three or four sliders. Encoding RGB color in one float is hard enough, but how to encode RGBA into one float?
This really is a hard question and probably it is another area, where a general mapping abstraction library will be necessary.
Maybe a comprimise. We could make the R,G,B separate floats into a
symbol for the data structures, like:
r1g1b1, r0.53234g0.0123b1.0, r0g0b0
.hc
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver
On Wed, 29 Mar 2006, Frank Barknecht wrote:
My GEM patches OTOH have a lot of [unpack $1 $2 $3] constructs. Btw: It would be nice if the GEM color objects would accept lists instead of being forced to [unpack 0 0 0] in front of every colorRGB object.
Someone else implemented that.
It's called GridFlow.
BTW, Jitter has got the same problem, just worse. You've got to pass your list through a messagebox like "aoutline $1, routline $2, goutline $3, boutline $4" if it's for setting the outline colour of some figure, for example.
Encoding RGB color in one float is hard enough, but how to encode RGBA into one float?
Take the RGB value as an integer 0..0xFFFFFF. If it's less than 0x800000, substract 0x1000000. Then multiply by 1<<(alpha-104).
To decode, compute alpha = int(log(abs($1))/log(2)+104). Then divide by 1<<(alpha-104). If it's less than 0, add 0x1000000. That gives you an integer 0..0xFFFFFF which is your RGB triplet.
Sorry, but it's really the easiest way (and almost the only way) to encode 32-bit RGBA in a 32-bit float.
If you want to encode it in 24 bits, use 6+6+6+6 bits, and if you want it to fit in 19 bits (because of Pd's... features) then use 5+5+5+4 or something.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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
On Fri, 24 Mar 2006, Frank Barknecht wrote:
Surely, however as it currently is, we have at least 3 color schemes in Pd and Gem: IEM colors, which nobody really understands,
I've posted decoders for them a few times.
[* -1] | [+ 1] | |------. [>> 8] [& 255] -> blue | [>> 8] [& 255] -> green | [>> 8] [& 255] -> red
And so the reverse process would involve [<< 8], etc.
The ones stored in .pd patches are slightly different, they use [>> 6] [& 63] because of a limitation of pd (can't print exact ints over a million)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Fri, 24 Mar 2006, Frank Barknecht wrote:
Surely, however as it currently is, we have at least 3 color schemes in Pd and Gem: IEM colors, which nobody really understands,
I've posted decoders for them a few times.
Another is "expr -65536 * $i1 - 256 * $i2 - $i3 - 1"
Thanks for explaining them again, but actually I was just trying to be funny with that remark ("nobody understands") and I wanted to express, that I think the IEMgui color spec is way too complicated. It's not designed to be "parsed by humans".
If I read "bbb" or "0.7 0 Ã" I can think "light grey" or "medium red", however if I read "-1.23033e+07" I don't know what kind of color it is or if it's any different color than "-1.22552e+07". (The first is a light grey, the second a medium red.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle -
João Miguel Pais -
Mathieu Bouchard -
Miller Puckette -
zmoelnig＠iem.at