So what's wrong with version 1.2?

[MtnViewJohn]

This topic is a placeholder for discussion on whether the version 1.2 color model is fine, or needs work.

I can think of two things:

1. Inadequate control of hue. Adding, subtracting, and setting hue is not enough. In rose.cfdg I wanted to have the petals start as red at the periphery and trend to yellow in the center. But I kept overshooting past yellow to green. So I resorted to a hack of fading to transparent and having a solid yellow rose underneath unfade from transparent to solid.
   
   There needs to be a syntax for saying "add x to hue, but don't go past y" and probably also "take me x% closer to hue y". Also, the GarishRainbow example is not really that garish because I had to do something to stop it from going past purple back to red. I don't know what kind of feature we could add to stop the rainbow at purple. Maybe a general recursion depth limit.
2. I don't like that we created a new syntax element for specifying the color and alpha parameters. I wonder if we should just allow normal shape adjustments on the startshape line. If you want a canvas with color then you need to have a hue or sat adjustment in startshape, even if it is a meaningless 'hue =0'. To enable alpha you would need to have an alpha adjustment ('a =1' or 'a =0'). These color adjustments could also be used to set the background to something other than opaque white. But there are two things about this approach that are kind of ugly:
   1. The syntax allows transforms (size, rotate, flip, etc) but do we want to allow them to actually have meaning? If we did then we would have a strange hybrid: color adjusters change the background and geometry adjusters change the initial shape.
   2. Some canvas parameters, such as watercolor blending, will not have a corresponding shape adjustment factor.
   So should we stick with the parameter list approach or come up with a new way of specifying things like color, alpha, depth, ink-blending, etc?

[lagroue]

About the startshape parameters :

The idea behind the beta syntax, which is specifying which kind of canvas is requested, is just fine.

• BW ? color ? alpha ?
• x ? y ? z(3D) ? t(ime) ?

Very clean.

Except for one point : it is useless.
Actually, one rule having hue or alpha concern (or z or time) could automatically make the canvas fit to it.

This is not a complicated guess. To be absolutely clean, canvas should adapt on the first triggered rule with special features. To be clean enough, a quick parse of the cfdg file make it possible to guess the canvas type before launching the rendering.

So in my point of view, these first parameters can be totally avoided.


BUT, remains the background color problem.

One solution is just drawing a huge SQUARE at the beginning.
But the rules may extend beyond its limits. And there is still the auto-centering feature which would trigger nasty side effect.

Another solution is just drawing a huge SQUARE, with infinite scale :

Code: Select all

startshape scene

rule scene {
  SQUARE { s infinite hue 200 brightness 0.5 saturation 1 }
  actualscene { }
}

Or to introduce a new basic shape :

Code: Select all

rule scene {
  BACKGROUND { hue 200 brightness 0.5 saturation 1 }
  actualscene { }
}

We could even draw several backgrounds, with some alpha, and that could help producing some nice pictures.


Behind all this post, is the idea that any parameter which could be set in the startshape line, could also be set in the startshape-rule. We could even imagine that the startshape line could be avoided, and make the "main" rule the first one, always. Developers will understand.

Code: Select all

rule main { helloworld { } }

[lagroue]

--------- Obsolete post ---------

What you see on hue, I also see it on saturation and brightness. Color is not only hue.

Let's move the "hue problem" to the one I would call the "scale problem". To be short : I don't find it clean that scale only applies to x and y.

Imagine a syntax like :

Code: Select all

rule scene {
  drawing {
    scale_x 1
    scale_y 0.5
    scale_hue 0.5
    scale_saturation 0.2
    scale_brightness 0.8
    hue 80
    saturation 0.5
    brightness 0.6
  }
}

This will narrow the hue, saturation and brightness range, thus allowing the targetting of a particular color range.

And extend the scale parameters to every aspect of shapes (including rotation, skew, etc.)
And make cfdg files more verbose.

This are just raw ideas.

...We (I ?) wish we weren't bound to run across the whole hue range, leading to not-so-beautiful picures, or making us hack with alpha or other parameters to fix unintended colors.

[Guest]

Last but not least : alpha enforces the order of drawing concept.
Because red 100% + blue 50% isn't blue 50% + red 100%.

[Guest]

Developers will understand.

Yet, C and its sucessors aren't the only programming languages. There is no such main clause in Prolog, for instance.

[lagroue]

Hue again : let's go into maths, apologize about the false "scale problem", and give another argument for a hue scale parameter.

Context free parameters which are real numbers (x, rotation, skew, hue...) go either positive, either negative infinite, when regularly applied a transformation such as in rule A { A { x n } }.

We were able to cope with those infinites by reducing the size :

Code: Select all

startshape scene

rule scene {
	SQUARE { x 0.5 }
	scene [ x 1 s 0.5 ]
}

The limit of x is 1 + 1/2 + 1/4 + ... = 1/(1-1/2) = 2

Now what's about hue ? Weren't we able to narrow the x range ?

Code: Select all

startshape gradient
rule gradient {
	SQUARE { sat 1 brightness 1 }
	gradient [ hue 30 scale_hue 0.5 ]
}

1st square will have hue 0 (red)
2nd one will have hue 30
3rd one will have hue 30+30/2
4rd one will have hue 30+30/2+30/4
"last" one will have hue 30+30/2+30/4+30/8+... = 30/(1-1/2) = 60 (yellow)

So we have a gradient from red to yellow, without ambiguity. And we don't lose the context-free paradigm by setting a "limit" or a "target" to hue.

For the apology : parameters in [0,1] always go to 1 or 0, whatever scale applied. I was irrelevant. There was no "scale problem".

[MtnViewJohn]

Since the CFDG file is fully parsed before the canvas is created it would be trivial to figure out the canvas type from the actual shapes themselves. I don't know why I didn't think of that. But I guess we should keep the parameter syntax for canvas configurations that don't show up in shapes, such as the water-color blending mode. Also, it will be a convenient way to specify the background color.

I like your color scaling idea. I like the idea of having negative scales and scales that are greater than 100%. I think that sat/bright/alpha could benefit from scaling too. Instead of adding a hue_scale token, how about having the hue scale syntax be 'hue 50%' to scale subsequent hue adjustments by 50%? I'm pretty sure that this would be easy to do in yacc.

While I was trying to userstand your color scaling idea I came up with a color bounding idea. Currently hue changes are unbounded and sat/bright/alpha changes are bounded between 0 and 1. What if we added a syntax to create different bounds for hue/sat/bright/alpha? hue/sat/bright/alpha followed by one number would adjust the color within the previously defined limit range. hue/sat/bright/alpha followed by two numbers would redfine the color bounds for subsequent color adjustments. Yacc already handles size with one or two parameters, so it can handle hue/sat/bright/alpha too.

[lagroue]

So we have a gradient from red to yellow, without ambiguity.

Let's give a practical example.
Here is some python to output a gradient from red to yellow :

Code: Select all

# begining hue : red
hue=0
# end hue : yellow
end_hue = 60

# hue geometry starts normal
geometry_hue=1

# size starts at 1 and will scale by 0.9
size=1.0
scale_size = 0.9

# let's compute the hue shift, given a scale_hue which would draw a nice gradient
scale_hue = 0.8
shift_hue = (end_hue-hue)*(1-scale_hue)

print "/* Simulation of :"
print
print "startshape scene { color }"
print "rule scene {"
print "	SQUARE { }"
print "	scene { s %f hue %f scale_hue %f saturation 1 brightness 1 }" % (scale_size, shift_hue, scale_hue)
print "} */"
print
print "startshape scene { color }"
print "rule scene {"

# output SQUARES until colors are close enough
while abs(end_hue-hue) > 0.5:
	print "SQUARE { s %f hue %f saturation 1 brightness 1 }" % (size, hue)
	# apply size scaling
	size *= scale_size
	# apply hue shift
	hue += shift_hue*geometry_hue
	# apply hue scale which changes the hue geometry
	geometry_hue *= scale_hue
	
print "}"

And the generated cfdg file :

Code: Select all

/* Simulation of :

startshape scene { color }
rule scene {
	SQUARE { }
	scene { s 0.900000 hue 12.000000 scale_hue 0.800000 saturation 1 brightness 1 }
} */

startshape scene { color }
rule scene {
SQUARE { s 1.000000 hue 0.000000 saturation 1 brightness 1 }
SQUARE { s 0.900000 hue 12.000000 saturation 1 brightness 1 }
SQUARE { s 0.810000 hue 21.600000 saturation 1 brightness 1 }
SQUARE { s 0.729000 hue 29.280000 saturation 1 brightness 1 }
SQUARE { s 0.656100 hue 35.424000 saturation 1 brightness 1 }
SQUARE { s 0.590490 hue 40.339200 saturation 1 brightness 1 }
SQUARE { s 0.531441 hue 44.271360 saturation 1 brightness 1 }
SQUARE { s 0.478297 hue 47.417088 saturation 1 brightness 1 }
SQUARE { s 0.430467 hue 49.933670 saturation 1 brightness 1 }
SQUARE { s 0.387420 hue 51.946936 saturation 1 brightness 1 }
SQUARE { s 0.348678 hue 53.557549 saturation 1 brightness 1 }
SQUARE { s 0.313811 hue 54.846039 saturation 1 brightness 1 }
SQUARE { s 0.282430 hue 55.876831 saturation 1 brightness 1 }
SQUARE { s 0.254187 hue 56.701465 saturation 1 brightness 1 }
SQUARE { s 0.228768 hue 57.361172 saturation 1 brightness 1 }
SQUARE { s 0.205891 hue 57.888938 saturation 1 brightness 1 }
SQUARE { s 0.185302 hue 58.311150 saturation 1 brightness 1 }
SQUARE { s 0.166772 hue 58.648920 saturation 1 brightness 1 }
SQUARE { s 0.150095 hue 58.919136 saturation 1 brightness 1 }
SQUARE { s 0.135085 hue 59.135309 saturation 1 brightness 1 }
SQUARE { s 0.121577 hue 59.308247 saturation 1 brightness 1 }
SQUARE { s 0.109419 hue 59.446598 saturation 1 brightness 1 }
}

[lagroue]

While I was trying to userstand your color scaling idea I came up with a color bounding idea. Currently hue changes are unbounded and sat/bright/alpha changes are bounded between 0 and 1. What if we added a syntax to create different bounds for hue/sat/bright/alpha? hue/sat/bright/alpha followed by one number would adjust the color within the previously defined limit range. hue/sat/bright/alpha followed by two numbers would redfine the color bounds for subsequent color adjustments. Yacc already handles size with one or two parameters, so it can handle hue/sat/bright/alpha too.

Do you really want to introduce a special, yet unheard, syntax for a feature that can be handled by a geometry change ?

"size", "skew" and "rotation" already apply a geometry change to the {x,y} space. If you extend the geometry changes to hue, you use the same toolbox as today, you can achieve the requested effects, and you don't introduce new concepts such as boundings. (Yes, I'm very conservative.)

Your idea has a big advantage : it's easy to tell which color is requested.

Mine has a nasty side effect : you never know what hue shift should be applied, depending on the end hue and the hue geometry change (see the python code above, which computes it for me).

If I was picky, I'd recommend introducing functions...
This rule would draw a gradient from any hue to this hue+60 :
rule A { A { hue gradient(60,0.9) scale_hue 0.9 } }
where gradient(hue, scale_hue) returns hue*(1-scale_hue)

OK. Let's take a nap

[lagroue]

A slight change in code, and some variations on the scale_hue parameter.

Code: Select all

# begining hue : red
hue=0
# end hue : yellow
end_hue = 60

# hue geometry starts normal
geometry_hue=1

# size starts at 1 and will scale by 0.9
size=1.0
scale_size = 0.95

# let's compute the hue shift, given scale_hue.
scale_hue = -0.94
shift_hue = (end_hue-hue)*(1-scale_hue)

print "/* Simulation of :"
print
print "startshape scene { color }"
print "rule scene {"
print "	CIRCLE { }"
print "	scene { s %f hue %f scale_hue %f saturation 1 brightness 1 }" % (scale_size, shift_hue, scale_hue)
print "} */"
print
print "startshape scene { color }"
print "rule scene {"

# output 50 CIRCLES
for a in range (0,50):
#while abs(end_hue-hue) > 1:
	print "CIRCLE { s %f hue %f saturation 1 brightness 1 }" % (size, hue)
	# apply size scaling
	size *= scale_size
	# apply hue shift
	hue += shift_hue*geometry_hue
	# apply hue scale which changes the hue geometry
	geometry_hue *= scale_hue
	
print "}"

With negative scales (), we can observe some "série géométrique non monotone convergente" - don't know how to translate.
In python : scale_hue=-0.91, end_hue = 180

Code: Select all

/* Simulation of :

startshape scene { color }
rule scene {
	CIRCLE { }
	scene { s 0.950000 hue 343.800000 scale_hue -0.910000 saturation 1 brightness 1 }
} */

startshape scene { color }
rule scene {
CIRCLE { s 1.000000 hue 0.000000 saturation 1 brightness 1 }
CIRCLE { s 0.950000 hue 343.800000 saturation 1 brightness 1 }
CIRCLE { s 0.902500 hue 30.942000 saturation 1 brightness 1 }
CIRCLE { s 0.857375 hue 315.642780 saturation 1 brightness 1 }
CIRCLE { s 0.814506 hue 56.565070 saturation 1 brightness 1 }
CIRCLE { s 0.773781 hue 292.325786 saturation 1 brightness 1 }
CIRCLE { s 0.735092 hue 77.783535 saturation 1 brightness 1 }
CIRCLE { s 0.698337 hue 273.016983 saturation 1 brightness 1 }
CIRCLE { s 0.663420 hue 95.354545 saturation 1 brightness 1 }
CIRCLE { s 0.630249 hue 257.027364 saturation 1 brightness 1 }
CIRCLE { s 0.598737 hue 109.905099 saturation 1 brightness 1 }
CIRCLE { s 0.568800 hue 243.786360 saturation 1 brightness 1 }
CIRCLE { s 0.540360 hue 121.954412 saturation 1 brightness 1 }
CIRCLE { s 0.513342 hue 232.821485 saturation 1 brightness 1 }
CIRCLE { s 0.487675 hue 131.932449 saturation 1 brightness 1 }
CIRCLE { s 0.463291 hue 223.741472 saturation 1 brightness 1 }
CIRCLE { s 0.440127 hue 140.195261 saturation 1 brightness 1 }
CIRCLE { s 0.418120 hue 216.222313 saturation 1 brightness 1 }
CIRCLE { s 0.397214 hue 147.037696 saturation 1 brightness 1 }
CIRCLE { s 0.377354 hue 209.995697 saturation 1 brightness 1 }
CIRCLE { s 0.358486 hue 152.703916 saturation 1 brightness 1 }
CIRCLE { s 0.340562 hue 204.839437 saturation 1 brightness 1 }
CIRCLE { s 0.323534 hue 157.396113 saturation 1 brightness 1 }
CIRCLE { s 0.307357 hue 200.569538 saturation 1 brightness 1 }
CIRCLE { s 0.291989 hue 161.281721 saturation 1 brightness 1 }
CIRCLE { s 0.277390 hue 197.033634 saturation 1 brightness 1 }
CIRCLE { s 0.263520 hue 164.499393 saturation 1 brightness 1 }
CIRCLE { s 0.250344 hue 194.105552 saturation 1 brightness 1 }
CIRCLE { s 0.237827 hue 167.163947 saturation 1 brightness 1 }
CIRCLE { s 0.225936 hue 191.680808 saturation 1 brightness 1 }
CIRCLE { s 0.214639 hue 169.370465 saturation 1 brightness 1 }
CIRCLE { s 0.203907 hue 189.672877 saturation 1 brightness 1 }
CIRCLE { s 0.193711 hue 171.197682 saturation 1 brightness 1 }
CIRCLE { s 0.184026 hue 188.010109 saturation 1 brightness 1 }
CIRCLE { s 0.174825 hue 172.710800 saturation 1 brightness 1 }
CIRCLE { s 0.166083 hue 186.633172 saturation 1 brightness 1 }
CIRCLE { s 0.157779 hue 173.963814 saturation 1 brightness 1 }
CIRCLE { s 0.149890 hue 185.492929 saturation 1 brightness 1 }
CIRCLE { s 0.142396 hue 175.001434 saturation 1 brightness 1 }
CIRCLE { s 0.135276 hue 184.548695 saturation 1 brightness 1 }
CIRCLE { s 0.128512 hue 175.860688 saturation 1 brightness 1 }
CIRCLE { s 0.122087 hue 183.766774 saturation 1 brightness 1 }
CIRCLE { s 0.115982 hue 176.572235 saturation 1 brightness 1 }
CIRCLE { s 0.110183 hue 183.119266 saturation 1 brightness 1 }
CIRCLE { s 0.104674 hue 177.161468 saturation 1 brightness 1 }
CIRCLE { s 0.099440 hue 182.583064 saturation 1 brightness 1 }
CIRCLE { s 0.094468 hue 177.649412 saturation 1 brightness 1 }
CIRCLE { s 0.089745 hue 182.139035 saturation 1 brightness 1 }
CIRCLE { s 0.085258 hue 178.053478 saturation 1 brightness 1 }
CIRCLE { s 0.080995 hue 181.771335 saturation 1 brightness 1 }
}

With |scale_hue|>1, the "série géométrique" doesn't have a limit, as we can see :
In python : scale_hue = 1.5, end_hue = 60

Code: Select all

/* Simulation of :

startshape scene { color }
rule scene {
	CIRCLE { }
	scene { s 0.950000 hue -30.000000 scale_hue 1.500000 saturation 1 brightness 1 }
} */

startshape scene { color }
rule scene {
CIRCLE { s 1.000000 hue 0.000000 saturation 1 brightness 1 }
CIRCLE { s 0.950000 hue -30.000000 saturation 1 brightness 1 }
CIRCLE { s 0.902500 hue -75.000000 saturation 1 brightness 1 }
CIRCLE { s 0.857375 hue -142.500000 saturation 1 brightness 1 }
CIRCLE { s 0.814506 hue -243.750000 saturation 1 brightness 1 }
CIRCLE { s 0.773781 hue -395.625000 saturation 1 brightness 1 }
CIRCLE { s 0.735092 hue -623.437500 saturation 1 brightness 1 }
CIRCLE { s 0.698337 hue -965.156250 saturation 1 brightness 1 }
CIRCLE { s 0.663420 hue -1477.734375 saturation 1 brightness 1 }
CIRCLE { s 0.630249 hue -2246.601562 saturation 1 brightness 1 }
CIRCLE { s 0.598737 hue -3399.902344 saturation 1 brightness 1 }
CIRCLE { s 0.568800 hue -5129.853516 saturation 1 brightness 1 }
CIRCLE { s 0.540360 hue -7724.780273 saturation 1 brightness 1 }
CIRCLE { s 0.513342 hue -11617.170410 saturation 1 brightness 1 }
CIRCLE { s 0.487675 hue -17455.755615 saturation 1 brightness 1 }
CIRCLE { s 0.463291 hue -26213.633423 saturation 1 brightness 1 }
CIRCLE { s 0.440127 hue -39350.450134 saturation 1 brightness 1 }
CIRCLE { s 0.418120 hue -59055.675201 saturation 1 brightness 1 }
CIRCLE { s 0.397214 hue -88613.512802 saturation 1 brightness 1 }
CIRCLE { s 0.377354 hue -132950.269203 saturation 1 brightness 1 }
CIRCLE { s 0.358486 hue -199455.403805 saturation 1 brightness 1 }
CIRCLE { s 0.340562 hue -299213.105707 saturation 1 brightness 1 }
CIRCLE { s 0.323534 hue -448849.658561 saturation 1 brightness 1 }
CIRCLE { s 0.307357 hue -673304.487841 saturation 1 brightness 1 }
CIRCLE { s 0.291989 hue -1009986.731762 saturation 1 brightness 1 }
CIRCLE { s 0.277390 hue -1515010.097643 saturation 1 brightness 1 }
CIRCLE { s 0.263520 hue -2272545.146464 saturation 1 brightness 1 }
CIRCLE { s 0.250344 hue -3408847.719696 saturation 1 brightness 1 }
CIRCLE { s 0.237827 hue -5113301.579544 saturation 1 brightness 1 }
CIRCLE { s 0.225936 hue -7669982.369315 saturation 1 brightness 1 }
CIRCLE { s 0.214639 hue -11505003.553973 saturation 1 brightness 1 }
CIRCLE { s 0.203907 hue -17257535.330960 saturation 1 brightness 1 }
CIRCLE { s 0.193711 hue -25886332.996439 saturation 1 brightness 1 }
CIRCLE { s 0.184026 hue -38829529.494659 saturation 1 brightness 1 }
CIRCLE { s 0.174825 hue -58244324.241989 saturation 1 brightness 1 }
CIRCLE { s 0.166083 hue -87366516.362983 saturation 1 brightness 1 }
CIRCLE { s 0.157779 hue -131049804.544474 saturation 1 brightness 1 }
CIRCLE { s 0.149890 hue -196574736.816711 saturation 1 brightness 1 }
CIRCLE { s 0.142396 hue -294862135.225067 saturation 1 brightness 1 }
CIRCLE { s 0.135276 hue -442293232.837600 saturation 1 brightness 1 }
CIRCLE { s 0.128512 hue -663439879.256401 saturation 1 brightness 1 }
CIRCLE { s 0.122087 hue -995159848.884601 saturation 1 brightness 1 }
CIRCLE { s 0.115982 hue -1492739803.326902 saturation 1 brightness 1 }
CIRCLE { s 0.110183 hue -2239109734.990353 saturation 1 brightness 1 }
CIRCLE { s 0.104674 hue -3358664632.485529 saturation 1 brightness 1 }
CIRCLE { s 0.099440 hue -5037996978.728293 saturation 1 brightness 1 }
CIRCLE { s 0.094468 hue -7556995498.092440 saturation 1 brightness 1 }
CIRCLE { s 0.089745 hue -11335493277.138660 saturation 1 brightness 1 }
CIRCLE { s 0.085258 hue -17003239945.707991 saturation 1 brightness 1 }
CIRCLE { s 0.080995 hue -25504859948.561985 saturation 1 brightness 1 }
}

[MtnViewJohn]

OK, so the color bounds idea wasn't that great. Color scaling is a great idea but it only walks the color space in a logarithmic manner. This is good for a lot of things, but I would like to be able to walk the color space in a linear manner too.

One way to do this, and to also provide a lot of other capabilities, is to provide a configurable limit to recursion depth. Each unfinished shape would have a recursion limit, which would start at 4 billion for the startshape. The default adjustment for the limit would be to subtract 1, but a shape could have a 'limit n' adjustment to add or subtract a different number or a 'limit =n' adjustment to set the limit to some value n. If a shape has a limit of zero (or less) then it is dropped.

Giving the designer control over recursion depth would be useful for more than just controlling the range of hue. It would allow designers to have recursive shapes that terminate without shrinking to nothing. For example, create an arc of constant width over 60 degrees.

For the apology : parameters in [0,1] always go to 1 or 0, whatever scale applied. I was irrelevant. There was no "scale problem".

It is true that the parameters in [0,1] don't have a scale problem. But they do limit the designer to the asymptotes 0 and 1. I wonder if designers might want to set a different asymptote.

[vapocalypse]

Well, if I understood, the scale would give a logarithmic curve if less than 1, linear if equals to 1 and exponential if more than 1, right? This would give an excellent control over the hue shift.

Now, I also would like to suggest a layer control, detemining if a given rule overlaps (the way it is today, with drawing priority, where the most recent rule draws above the previously drawn), is above or below another.

The layer could be accumulated or a specific and immutable value:

layer =1 // would draw always in the layer number 1

layer 1 // would add a level to the current layer; and

layer -1 // would subtract a level

What do you think?

--
Apoc

[lagroue]

It's still impossible to get a linear gradient from red to yellow, though...

But...

Gradients take some hue space, but also some (x,y) space, don't they ?
And recursive things which aren't infinite in space are acheived logarithmicly, aren't they ?

So a gradient would be made of two logarithmic progressions at the same time, one in hue, the other in plane... Couldn't we acheive a linear gradient ?

Let's take this actual cdfg code, in B&W :

Code: Select all

startshape gradient

rule gradient {
	SQUARE { }
	gradient { x 0.005 s 0.99 1 b 0.01 }
}

(given scale factor 0.99, I get brightness = 1-0.99, and x = (1-0.99)/2)

It produces a balanced grey gradient : black left, grey 50% in the middle, white right, totally flat histogram in Photoshop (after a little blur effect to eliminate artefacts). Seems very linear to me. (Oddly, Photoshop's gradients' histograms aren't flat)

In hue space, it should be the same.
And we remain consistent.


OK, brightness is in [0,1] and is not like hue. But replace brightness by y, and we still are linear : gradient { x 0.005 y 0.005 s 0.99 b 0.01 }


So... doesn't scale eventually solves all our problems ?

[lagroue]

It is true that the parameters in [0,1] don't have a scale problem. But they do limit the designer to the asymptotes 0 and 1. I wonder if designers might want to set a different asymptote.

No more ideas. I'm dry. Tried hard, but nothing good has emerged.

A geometry change has some effects here too (looping on b = b+shift(1-b) and shift=shift*scale makes b converge to values lower than 1, actually), but in a way I can not understand (where did I forget my maths ?), and which behave weirdly compared to parameters like x, y and hue.

(Maybe it's a false convergence, with rounding occurring again on floating operations, in the same way as the sum of 1/n doesn't diverge on a computer.)

Setting asymptotes may be the right solution here.

[MtnViewJohn]

Mark and I are thinking that instead of a color scaling feature that the right thing to do is to completely drop the current model for changing hue and make hue changes asymptotic, like sat/bright/alpha. We would have a syntax for setting the target hue and then hue adjustments would get you x% toward the target:

Code: Select all

rule foo {
   bar { hue =60 }   // sets the hue to yellow
   bar { hue =+30 } // adds 30 to the current hue
   bar { hue =-30 }  // subtracts 30 from the current hue
   bar { hue |60 }    // sets the target hue to yellow
   bar { hue |+30 }  // adds 30 to the target hue
   bar { hue |-30 }  // subtracts 30 from the target hue
   bar { hue 0.30 }  // moves 30% toward target hue, counter-clock-wise
   bar { hue -0.30 } // moves 30% toward target hue, clock-wise

   bar { sat =0.5 }   // sets the saturation to 50%
   bar { sat |0.75 }  // sets the saturation target to 75%
   bar { sat 0.30 }   // increases saturation 30% toward target or 1
   bar { sat -0.30 }  // decreases saturation 30% toward 0 or target
}

The hue addition/subtraction adjustments in the current release are preserved, using the '=+x' and '=-x' syntax, but the default syntax is asymptotic. This will break all the existing color cfdg scripts, but we warned people that the color model may be wrong and that their scripts might get broken. Maybe we can provide a script translator to get people through the transition.

So here is the question: is the current color model OK as long as we add hue scaling. Or is hue scaling a band-aid for a broken color model?