Recent blog entries for nomis

Curves

raph wrote:

Also, two cubic Beziers can intersect at up to nine points, while I think it may be true that two Cornu spiral segments each traversing no more than 180 degrees of arc intersect at no more than two points.

This is a little bit unfair :-). If you limit bezier segments to traverse no more than 180 degrees of arc, the number of possible intersections goes most probably down (I managed to get four intersections easily, I doubt that it is possible to have more, but I might be wrong here).

Unless I misunderstood you, your assumption about a maximum of two intersections for two (180°-angle) cornu segments is wrong. Have a look at this image which shows three intersections. Since I don't have a tool to easily create cornu segments I used the image at mathworld for the shape of the cornu segment. The second segments (red) are flipped and 90°-rotated versions of the first segments.

Can you point me to some more in-depth literature? My knowledge is basically limited to the mathworld entry and I am curious on the parameter set used to pick a certain segment of the cornu spiral.

The ease of affine transformations for bezier segments basically stems from the fact, that all points on a segment are a linear (even convex) combination of the control points. I wonder how to transfer at least some of this ease to cornu segments. You really want to render your font correctly at any angle and you really want to be able to scale your font in X- and Y- direction independantly (especially when you want to adjust your font for small sizes to compensate the press gain). It is not at all obvious how to choose the parameters for cornu segments to be able to handle these needs.

In your diary entry from august 13th you mentioned a presentation from siggraph. Interesting read. I think this would be awesome for interpolating the coordinates of a quick mouse movement which sometimes result in jaggy brush strokes with a paint tool

FontFocus

It might be worth to think about a "global" optimizing step in the Y-direction (i.e. try to align baseline, x-height and ascent (of the capital letters) for a certain font size. So you'd avoid uneven base lines and still get more crisp bars. Maybe its just me (or the font...) but the Times example in your whitepaper gives a little "picket fence" impression. The Helvetica sample looks better, but of course Helvetica has a more uniform line width and the sample *has* a focussed capital-ascender.

Continuing the habit of updating Advogato every year... :-)

The Path tool is in a stable release of The GIMP and it seems to work. My contributions to the GIMP are currently limited to small fixes here and there. Currently I am looking at the code of potrace (which rocks) to improve the stroking of a selection boundary. Gimp really does a horrible job at doing this, especially with the libart stroking (not the fault of libart - the boundary of the selection is along the pixel boundaries, so that libart has no chance to do proper antialiasing...).

raph: FontFocus looks amazing. Hopefully you can work out a good scheme to make it available to the free software community. Does FontFocus work in X and Y direction? The Times-"T" suggests that it doesn't apply in Y direction, but you mentioned that it works word-based, so it might have preferred the ex-height because it is more important.

About curve primitives: I have no experience with cornu splines and I currently cannot imagine how they would be edited. I have some experience with bezier curves (obviously...) and I think that there is room for improvement in the "typical" user interface to edit them. The average program has the two anchors and two control points, with the control points being way off the actual curve. About four years ago Bernhard Herzog picked up a suggestion by me for sketch (now skencil) to enable the user to drag on any point of the bezier segment and have immediate control over the segment without having to do guesswork with the control points. A refined version of this is implemented in the Path tool of the GIMP. Do some clicks in the image to create some segments, and click-drag on arbitrary points of the path to drag the segment around.

When you got used to this you can use less control points to approximate a given shape manually. You don't need to subdivide a segment as often, which would make the path harder to handle.

The math is easy: You want to move the curve point at parameter t a certain delta, so simply add a scalar multiple of this delta to each of the two control points (the amount can easily be figured out when looking at the formula for the bezier curve). There even is a degree of freedom to distribute the change between the two control points. I used that to change the first control point when t is small, the second when t is big and a smooth transition inbetween.

Someone suggested to just change the length of the "control tangents" to move the dragged point around. This would have the advantage that "smooth" joins of bezier segments would keep this property without changing the neighbor segment. The obvious problem with this is, that this requires the tangents to be linearily independant. Also it would change the overall shape of the segment (e.g. introducing a loop) for big changes. Thats why I decided against this.

The current way feels quite natural and is IMHO fairly transparent to the user. I did not dare to actually make the control points invisible to the user, but they definitely became less important...

The point I am trying to make: I don't think that the fundamental primitive is that important. It is the way we present it to the user that makes the difference.

That having said: Cornu splines obviously will be approximated with e.g. beziers at some point, so we are actually talking about user interface here... :-)

Ok, I feel it is time for an update - the last entry in this diary now is one year old... :-)

In the meantime the thesis is finished, I am now Diplom-Mathematiker and have a job as scientific assistant in the Workgroup of Professor Merzenich (Programming Languages) at the University of Siegen. I moved to a new apartment, which is a great improvement over the old one.

The Path tool of The GIMP has made great steps forward, I am basically finetuning it now. It has been a huge amount of work, but when it started to work it simply kept rolling. It is nice to get something usable after the usability nightmare of the old "bezier select" tool.

It seems our reference artists share my opinion on that... :-)

Thanks to the work of neo it is now possible to import SVG-Paths into the Gimp, also it is possible to export Gimp-Paths as SVG. Vector-Layers definitely are becoming reality after the 2.0 release....

So basically life is good :-)

Zusammenhang zwischen Fraktaler Dimension und Konvergenzgeschwindigkeit der Spektralreihe bei rationalen Fraktalen

(this roughly translates to "The connection between fractal dimension and convergence speed of the spectral series for rational fractals")

This is the topic of my diploma thesis. Interestingly the topic has been given to me by a professor in the CS department, although it doesnt sound like this – but there is stuff like finite automatons and regular languages in it :-)

It is a mathemathics thesis though...

At the end of the last week the stuff I already wrote for the thesis suddenly shrank. I had cited some things from a book. It was a highly complicated way to be able to compute P^n quickly when P is a matrix (n matrix multiplications are expensive, especially when they appear in a limes for n->infinity...). It involved stuff like characteristic polynomials, partial fraction expansion, comparing coefficients, wild index shuffling and had some quite annoying prerequisites.

Last Friday I visited my supervising mathematics professor and he had a look into that stuff. He wanted to understand what actually happens there. After five minutes he found it: The theoretical base for this is the Jordan decomposition of matrices. And poof: If you write this down by means of the linear algebra suddenly the whole stuff suddenly becomes shorter, easier to understand and – that is the best thing about it – more general. :-)

However, the GIMPs new path tool suffers heavily because of this thesis...

spam - multi language problems

The graham/bayes approach to spam is interesting and seems to work quite well. However, it seems to have pretty major issues with multi-language mails and I am not sure how to fix this in a convenient manner.

I get lots of "good" english and german Mail, but there is by far more english spam than german spam in my inbox. This has the effect that a word that should appear in nearly every german mail like e.g. "ein" appears rarely in spam mails and more frequently in good mails. Suddenly a word that should behave neutral for detecting spam becomes a witness for a good mail. In the case of "ein" the spam probability is 0.05 in my database.

It is not that bad because I do not get too much german spam. However, it seems like a fundamental problem to me and it most probably cannot be adressed without different databases and a way to determine what language a mail contains (this most probably can work the same way as distinguishing between spam/nonspam). However, the training/sorting work would increase significantly - I usually don't sort my mails by language...

On the other hand the very same effect is useful for me with CJK-Mails - I don't speak any of these languages so there are no "good" CJK-Mails in my inbox. It is perfectly reasonable that the filter classifies them as spam...

Hi everybody. Having just watched Episode II I want to point all GUAD3C visitors who had a chance to visit Sevilla to two photos:

• http://natalieempire.free.fr/g-51.jpg
• http://algol.prosalg.no/~docpi/php/gallery/album07/dscf0023

Have fun :-)

I did a good thing. I made The GIMP libart dependant. Now the conversion from a polygon to a selection really gives great results. They sucked before (left side).

Now let's see, where we can use it for other fun stuff...

As I am interested in typography I could not resist to reply to raph's challenge with his lebe-Font.

From some sheets I have seen the most likely letters missing on your specimen sheet are: J, U, w and maybe K.

However, these letters look great in your font. You certainly did a good job. The only letter I think does not match fully is the U, which should IMHO have a more circular arch (not sure about the english terminology) and be a little bit less slanted.

And maybe the stem pointing to the upper right of the K should be more uniform - most of the other letters have quite uniform stems.

Anyway: I like your font very much.

Long time no diary... However, a reference in raph's diary reminded me to publish something i did some weeks ago. I had a look at ClearType and was disappointed too. So I wrote a small script-fu for Gimp which scales an image down, optimized for LC-Displays. However, this is just a raw sketch and sometimes has some colorful borders, but the results are definitely worth a look.

Gimpcon is over. Thanks to Sven and Mitch for organizing this great event.

I try to certify all people I've met from face to face. So I had to certify a lot of gimp-developers. All of them are really nice people :-)

The meeting was very constructive. Gimp 2.0 will really rock!