inkscape tracing

I finally decided to give inkscape a try at importing and vectorizing some of my doodles.

It did a much better job than I expected. It choked on some of the larger doodles, but then, I can’t really blame it for choking on say, doodle31.

Take a look at some of the example traced svgs. That just includes the SVG’s that do not crash firefox ;->

Which reminds me that I need to catch up on the doodle scanning. I think I’m one or two dozen behind.

Some Processing work

Some tests of using processing.

Processing is sort of a high level graphics language that compiles into java applets.

Note: These links all contain java applets, and have been known to crash a browser or two.

Processing seems nice. It’s very high level, with a C/java style syntax. Theres a simple bare bones IDE included. I like how it calls source files “sketches”. Kind of a nice semantic touch. It’s also open source.

See processing work at adrianlikins.com

gimp-a-thon continues

So, after not making much process on two different patches ( my C skills are so sad…), I decided to try to write something useful
to folks, including windows users.

So that meant script-fu. Which means relearning the not-even-close-to-even-a-minimal-Scheme implementation. I quickly remembered why I stopped writing script-fu scripts. The language implementation is horrendous, impossible to debug, and solely lacking in useful features (like say, file i/o, string handling, etc).

So, I wrote something, and stumbled across an error I couldn’t figure out. So I google “script-fu debugging”.

The first result is a link to a page I wrote. Ouch.

Whats worse, after reading it, it helped. Double ouch.

Anyway, I wrote a script to convert “image packs” to a set of brushes. It can be found at http://www.adrianlikins.com/misc/gimp.
It’s called images-to-brushes.scm.

gimp brush ideas and whatnot

A couple folks who read this over at layers.gimp.org and pixels.gimp.org and/or #gimp mentioned that I should let people know the various
works in progress I have going on, regardless of there current state.

So aside from the stuff at adrian.gimp.org/patches, I have a couple other
projects.

1. Adding support for rotating brush maps into the brushcore.

    This isn’t too hard actually. Just add some support for rotating temp-bufs (the structure that the brush masks are stored in, basically just a traditional “char *” pixmap plus some meta info.). Then plug it into gimpbrushcore at the approriate places. For the most part, this means finding the places we scale, and adding support for rotation as well. Then a couple ui things to add it to the dialogs. One interesting thing is the transformed brush cache can potentially get pretty big, since you can scale and rotate a brush, making for lots of things to cache.

    Now if your a graphics person, your probably saying “you have scale already, and your talking about adding rotation support, which not just add arbitrary affine transforms?”. Yup, why not?

    So, what the heck do rotated brushes buy you anyway? Well, since you can rotate based on the angle of the brush strokes, you can “align” the brush with the stroke. Some of the image hoses already do this to interesting effect.

    I have partial code for this somewhere.

2. Support for sampling the “background” image and computing the average color to use

    A very simple trick to make something look “impressionistic” is to average a groups of pixel’d colors, and replace all the pixels in the group with that color. With the right shaped “group”, it looks pretty cool. So, the idea is to choose the color to paint a brush stroke color with by averaging the colors under the brush stroke, and painting with that color. Add in scaling brushes, or brushes that follow the stroke direction, and you can get very interesting effects.

    An interesting question of course, is how to “average” colors. Just average the RGB colors is one approach. But converting the colors to HSV or HSL or CIE colorspaces might produce better results (I suspect CIE in particular, since thats a non linear transformation into a colorspace designed to similuate how the human eye actually works). But once the basic bits are there, thats all easy enough to changes. It would also be easy to add in computing average hue/sat/val, or “hottest” color, or most popular or dominate color (kind of an on the fly artistic color quantization). But mainly, I think it would look cool.

    Only issue from what I recall was figuring out which pixels are actually under the brush mask, and not just the brush bounding box. Also, how to weight in the alpha channel. Probably just premultiplying the mask into the background, and skipping fully transparent pixels is good enough.

    I have partial code for this somewhere.

3. A tool options/presets selector

    A given tool in Gimp has a lot of options, plus a “context” which includes the brush, colors, paint mode, etc. Starting in 2.2 or so, theres the option of saving “presets” of tool options. So you can recall say “chunky black brush with low opacity” and “single pixel brush with colors from gradient ‘foobar'”. However, the UI for doing this kind of sucks. Namely, you have to change to the tool, and then select the preset.

    I want a dialog with a list of tool options for all tools that I can oranize as I see fit. So that it is one click to switch from the crop tool with weird settings, to the brush you use for removing zits, to the smudge you use to curl hair. I think it would make the tool options presets much easier to use.

    I had some code for this, but it vanished in a reinstall at some point. I doubt much of the patch would apply to current gimp anyway.


An example of what you can do in my tree atm, which does not include any of the above ideas yet.

gimp stuff

Despite at one time being a fairly prolific gimp script writer (looks like I have about 23 in the main gimp distro, and probably another dozen scattered about), I haven’t written one in years. Partially because the primary scripting engine in gimp is “script-fu” which is a really rudimentary scheme like language and was always a real pain to debug.

But now, theres a gimp python plugin. Well, actually, theres been one for years, but I’ve been lazy and never made much use of it. So I got some idea in my head and decided it needed to be scripted. Writing gimp scripts in python is so much nicer than in script-fu. Not only is the language saner, but you have full access to the standard python libs.

Anyway, a couple rudimentary python gimp scripts are here. One to draw brush stroke preview images, one to convert a font into a series of brushes, and one to convert a font into a gimp image pipes (aka, animated brushes, or “hoses”). There not well tested or anything, and I have no idea if they work on anything but my machine. So they might not work on windows or osx.

screensaver ideas

Once upon a time, I wrote a screensaver for xscreensaver. So, though I’ve barely looked at xscreensaver code in years, I still occasional think about ideas for screensavers.

1. A “meta” screensaver. This would render any other screensavers into a texture, that would get texture mapped to some 3d object. You could even go recursive if you wanted.

2. A version of webcollage that would point at images sources that are Creative Commons. This would be pretty easy.

3. A fake road map generator. Just randomly create something that kind of looks like a streep map. City maps would be easiest, but highway style maps would be cool as well. Think google maps, but totally bogus.

4. “old growth”, a screensaver that would draw what looks like a cross section cut out of a old tree, and then label the rings with historical dates and info. Something sort like this.