Color models and language addittions, was Waiting rules...

[aaronstj]

PHP version
http://korsh.com/cfdg/

I'm a pretty big fan of this site...I haven't taken the time to learn his additions to the language, but it clearly LOOKs awesome.

I feel pretty strongly about being careful about any language additions, though. Mark and John seem to be the same way.

(this post should probably be moved to the other board)

One of the biggest things to resolve before dealing with opacity, stretching, flipping, colors, etc is how shapes are prioritized for drawing. i.e., a CFDG programmer (all of us who use it) should have a good idea of what will end up on top of what.

Currently nonterminal shapes are stored in a queue. On a nonterminal replacement it's pulled off the front and thrown on the back. On a terminal replacement it's thrown in the front of the drawing queue.

So basically the ordering is determined by how nested it was.

One complication comes when temp files are written. It obviously gets difficult to truly maintain a queue... I'm not sure what Mark and John's versions do for this. On my original implementation predictable sorting fell apart. As soon as you had temp files shit got stacked in weird ways.

This never mattered when all we had was black! Or with trees where branches crossed randomly.

cc

[aaronstj]

Korsh's color model looks to be about bang on for what would be best (imo). It looks like a lot of the other extentions have to do with things like absolute positioning and size, which I think is probably a Bad Thing (and you guys do, too, I believe). I agree that care needs to be taken about adding language elements, but to use the HSB color model, you would just need to add a couple of parameters to rule invocation - one for hue and one for saturation - that would work exactly like brightness. If your wanted to do a color map, though, that would take a whole new language structure. A color map does seem like it would somehow stands apart from the the rest of the CFDG, kind of like metadata. I'm not sure what the best way to incorporate it/think about it would be.

[lagroue]

1- On absolutes : they don't break the context-free paradigm.

2- On color : HSB is a good color model, just a RVB. One other post talked about r/theta versus x/y. Same idea apply : sometimes one model is better, sometimes the other. I have no special request, except that CMJN is my favorite (I'm kidding)

3- On overlapping artefacts : Not all spatial overlappings are meaningful. In present implementation, no overlapping meaning can be implemented. So far, so good : let's wait for somebody showing a grammar where overlapping is meaningful (when I think of thousands overlapping shapes, my CPU melts)

Now, I go in vacations. Hi, folks !

[MtnViewJohn]

Once we add hue and saturation we would have to add alpha. Then people could do all sorts of post-processing tricks with their images. I think I would prefer to use 'hue' and 'sat' instead of 'c' and 't'. I don't want to be constrained by Korshykov's extensions to the syntax because I think there are better ways to do what he does.

[aaronstj]

I'm not sure why you would "have" to add alpha (unless you mean the people would just start demanding it). As for the exact names of the parameters, that's trivia. Whatever it ends up being (if anything) is ok with me.

[Stephen Deken]

I've got a patch I slapped together yesterday which adds hue/h and saturation/sat to the language. I'm not versed in the arguments against this, and it works just peachy, so here you have it.

Hue is simply incremented by the specified amount; saturation is handled like brightness.

Patch here:

http://awdang.com/junk/ContextFree.patch

Patch with `patch -p1 < ContextFree.patch`

--sjd;

[aaronstj]

Awesome work. It looks like the GUI clients need to be updated, too. You updated the OSX client. I went ahead and, working from your patch as a starting point, updated the Windows client.

Patch is at http://aaronstj.com/cfdg/ContextFree-Win32Color.patch
Binary is at http://aaronstj.com/cfdg/ContextFree.exe

Edit:

The patch is against Stephen's patch, so if you want to build it yourself, you'll need to patch the source tree with his patch and then with ContextFree-Win32Color.patch. Also, on my Windows box using patch.exe from http://unxutils.sourceforge.net/, I needed to use "patch -p0 < ContextFree.patch", not "-p1".

[Stephen Deken]

I updated my patch to roll in the changes to the Windows client made by aaron. I also added a few other tokens to the grammar: scalex/sx, scaley/sy, and scale (synonym for size/s).

I rearranged things a bit so that it was easier to do the transforms on the ellipses. It could probably use a bit of cleaning up.

The patch: http://awdang.com/junk/ContextFree.patch
OSX binary: http://awdang.com/junk/ContextFree.dmg

Bon appetit!

--sjd;

[phatcat]

For those of us not in the know, is there a windows binary about that a n00b an dl and be happy? (dl'd what I thought was the patched binary above but the hue / sat modifiers didn't affect the shapes -- didn't raise any syntax errors either, strangely). If someone's willing to post, I'd be much oblidged.

[MtnViewJohn]

I also couldn't get color to work on the Windows binary and the scalex and scaley adjustments gave me a syntax error. Neither of the patches applied fully either against the source tree at ozonehouse.com so I couldn't build it. We use a revision control system called 'darcs' http://www.darcs.net/ which is a decentralized RC system based on a super-robust patching engine.

There is no real argument against adding color, the camel's nose entered the tent with the brightness adjustment. But there is an issue that either needs to be solved or resolutely swept under the rug: what to do with overlapping shapes of different colors. The current color blending model just splats the new shape on top of the old. Everyone accepts this because the order that shapes appear is well defined... until you spill unfinished shapes to temp files (which I have never seen happen). Spilling finished shapes is fine.

One solution is to use an ink-like color blending model where the colors from the two shapes mix in an order independent way (old + new - old*new). This would be done independently for R, G, and B. But this causes overlapping shapes of the same color to be different in the overlapping part. Some people might design with this in mind but most people will hate it.

Another idea is to use the 3D hardware that we all have now and add a 16-bit depth buffer to our 32-bit RGBA buffer (you need alpha to blend the anti-aliased edges). Each shape would be assigned a depth according to its recursion distance from the startshape. I think this would be popular.

[Stephen Deken]

The patches were built against release, not tip. I'll grab the latest darcs source and rebuild the patch. I also couldn't test the Windows version as I'm constrained to my superior platform.

[aaronstj]

Whereas, unfortunately, I am constrained by my inferior platform. Next time I find two thousand bucks lying around, I'll buy Powerbook, I swear. Stupid iPod already has me addicted to buying things from the Apple store.

Anyway, back on topic. I assure you that the windows version works. To see color, keep in mind that brightness and saturation both have to be more than 0, or you'll still get black/grey. Here is some quick code to test that it's working:

Code: Select all

startshape TEST
rule TEST {
	CIRCLE {}
	TEST { s .95 y .5 b .1 r 25 sat .1 hue .02}
}

As for scalex / scaley, it's not in the Windows binary I released. If you run Stephen's aggregate patch against the release source code and build it, I imagine scalex / scaley will be working fine with no additional changes to the Windows client.

[Stephen Deken]

I've got the latest darcs source patched, with two bugs related to negative scaling factors and rotation fixed. What darcs command is the preferred way to create the patch?

[phatcat]

Ahh! It was the n00b showing. Thanks, you are absolutely right as I had not figured out values for hue / sat need to be fractions. Now ... if we had a 1.1 patched.... hehe.

Whereas, unfortunately, I am constrained by my inferior platform. Next time I find two thousand bucks lying around, I'll buy Powerbook, I swear. Stupid iPod already has me addicted to buying things from the Apple store.

Anyway, back on topic. I assure you that the windows version works. To see color, keep in mind that brightness and saturation both have to be more than 0, or you'll still get black/grey. Here is some quick code to test that it's working:

Code: Select all

startshape TEST
rule TEST {
	CIRCLE {}
	TEST { s .95 y .5 b .1 r 25 sat .1 hue .02}
}

As for scalex / scaley, it's not in the Windows binary I released. If you run Stephen's aggregate patch against the release source code and build it, I imagine scalex / scaley will be working fine with no additional changes to the Windows client.

[MtnViewJohn]

Ah, I forgot to increase the brightness.

I wouldn't bother with scalex/y now that version 1.1 is out. I'm pretty sure that you can't really implement general anisotropic scaling of shapes without resorting to affine transform matrices.

I have actually re-implemented color in v1.1, stealing code from the patches. But I did it a little differently:

1. I did RGBA instead of RGB
2. I made hue be from 0 to 360, not 0 to 1

http://www.ozonehouse.com/ContextFree/C ... eColor.exe

There are a couple things that are needed before this is ready for release:

• We need a color picker so that users can figure out what HSB values to use.
• We need to copy Yevgen Korshykov's =value syntax so that people can control hue directly
• We need to keep the ability to do 8-bit gray-scale, so that people can do 30,000x30,000 images w/o killing themselves
• The temp shape files are becoming huge because the shape class is growing (Did you notice yet that reading/writing temp files takes 3x longer on v1.1?) They need to be compressed.
• The user needs to be able to set there background. It can't just be white.