Suggestion for the saturation and the brightness parameters

Let the developers know what you think of the software and what can be done to either improve the CFDG language or the Context Free program.

Moderators: MtnViewJohn, chris, mtnviewmark

Post Reply
User avatar
Posts: 50
Joined: Sat Aug 05, 2006 5:28 pm
Location: Annecy, France

Suggestion for the saturation and the brightness parameters

Post by Guigui »

That would be usefull and fun if the saturation and the brightness had no limit.

To do that, as it is effective between 0 and 1, you can say that '2' goes back to '0', '3' is '1', '4' is '0', etc…
So 'sat' ans 'b' could be include (and really used) into unending rules. Like the 'hue' parameter.

Something else. Does the 2.0 is soon ready? :roll:
Anyway, thank you for all the people that work on the Context Free App. I love it, it's fun and … metaphysical. :wink:[/b]

User avatar
Site Admin
Posts: 875
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California

Post by MtnViewJohn »

Your idea is great. I wish we had thought of it a long time ago. But we are stuck with the current finite color space. We would need some sort of switch in the cfdg file to indicate whether the color space is finite or infinite (repeating endlessly saturation, brightness, and alpha). Actually, what I think you are proposing is a four-dimensional color space.

When Chris added brightness to cfdg over a year ago he made it finite and asymptotic, which made a lot of sense at the time. But now that we have the color limit feature it makes sense for brightness, saturation, and alpha to be like hue and use limits to asymptotically bound color changes.

Posts: 17
Joined: Fri Mar 30, 2007 9:10 pm

Another vote for infinite colorspace

Post by jeremydouglass »

I'd also dearly love infinitely repeating brightness, saturation, and alpha that behaved like hue (e.g. 1.5 = .5, 2 = 0, 2.5 = .5, 3 = 1 etc.)

I think you are right that it is a big enough backwards compatibility issue that you would need to add one or more directives. It must seem like a paint to implement two internal models and a bunch of new directives - but if you are interested, I have a suggested syntax for a single directive:

limits { b 1 sat 1 a 1 }

When unspecified limits are set to 1 by default, this gives normal behavior - just like background. Setting them to zero makes them infinite (cyclical).

The inelegant thing about this is that the syntax strongly implies that limit { b .5 sat .5 a .5 } would do something, due to its similarity to shape syntax, when in fact that would be nonsense. There are two things could be specified in the colorspace - limited/unlimited ( a binary - are there any other binaries in Context Free? ) and scale. So an idealized directive that gave you total control might look like this:

colorspace { [aspect] [(un)limited] [limit] [initial value] }

So, for example, the default colorspace directive that emulates CF 2.0's setup would say:

colorspace { a 1 1 0 b 1 1 0 sat 1 1 0 hue 0 360 0 }

"alpha-limited-limit is 1-initally 0
bright-limited-limit is 1-initially 0
sat-limited-limit is 1-initially 0
hue-unlimitied-'limit' is 360-initially 0"

...whereas writing your own colorspace might look like:

colorspace { a 0 1 0 b 0 1 1 sat 0 1 0 hue 0 100 50 }

That is, alpha is unlimited, bright is unlimited and starts at 1, hue is a space of 100 values and starts at 50...

Granted, this goes way overboard, and implements features I'm not sure anyone would want (e.g. remapping hue). Still, I think a subset might be both reasonably easy to parse and well received...

One last alternative: Make make zero the default limit, and anything else the cycle limit. This avoids binary values and makes defining a limit more intuitive. So:

limits { a 0 b 0 sat 0 }

Is the default and a special case - there is no limit, so a 'hard' limit is set at 1. However:

limits { a 1 b 1 sat 1 }

puts the soft limit (inflection point) at 1, while:

colorspace { a .5 }

puts the inflection point at .5 - so

0.5 = 1
1.0 = .5
1.5 = 0
2.0 = .5 etc.

and "colorspace { a 20.5 }" etc. is valid, just like { hue 900 }. It is a bit wacky that "colorspace { a 0 }" changes the mode to the original default limited... but nobody using the directive is going to be interested in the default behavior, so maybe that's acceptable...?

Post Reply