Timeout

It’s lights out from now to the defense. See you on the other side!

Why do sites even have passwords?

Every time I have to log in to a reviewer website I forget the password. I simply hit “reset password”, which takes me through a mostly-pleasant challenge-response kind of email exchange. So the question I have is: why do we even have passwords for these sites anymore? Can’t an email exchange be the default authentication mode? With cookies, the credentials can live for a longer time anyway, and this neatly pushes the password problem to the email account.

Tweet from Emacs

In my eternal struggle to catch up with the cool kids, I’ve decided to join twitter. If you like Emacs, just throw this in your ~/bin after installing python-twitter. Then, M-! tweet Okay the poop is coming out. Incidentally, that’s how you get old-school bonus points with twitter and iPhone: use twitter in an emacs session from an ssh shell in your iphone.

Cool paper: Visibility-Driven Transfer Functions

It seems I come across cool papers faster than I can write about them (that is, there’s a backlog of 10 papers I have been meaning to write about) This time, it’s “Visibility-Driven Transfer Functions” by Correa and Ma, Pacific Vis 2009. A pretty typical problem with transfer function assignment is that you will “run out of opacity”: if you assign values that are too high for some scalars, they will occlude inner surfaces. This happens a lot in practice on day-to-day volume render usage. I know it from personal experience, and because I have looked at the exploration trail of students on volume rendering assignments.

The cute idea of this paper, the way I see it, is to interpret a (simple, vanilla opacity 1D) transfer function as a “request for visibility”.  That is, if you assign high opacity to four different scalars, what you really meant is “I want to see these voxels more than the other ones”. The way this works is that the authors compute a “visibility histogram”, which is an image-based measurement of how much each scalar is visible in the final rendering. If a visibility histogram is low where a TF opacity assignment is high, it means the TF does not do a good job for this particular view angle. So now you can explicitly optimize the TF so that the visibility histogram is appropriate. Pretty simple  idea (in the best possible sense), and the results are very encouraging. I expect this to be widely adopted in the future.

One comment I have is the following: it seems that for most viewing angles, the TF after optimization is essentially a linear ramp of opacities for each interesting nested isosurface. If this were uniformly the case, then the optimization would be much simpler. Correa and Ma show a situation where this is not the case (figure 9d), and I think I have a theory which explains that. But it requires some setup, so bear with me.

First, there’s another cool paper that I’ve been meaning to write about: “Scale Invariant Volume Rendering”, Kraus, Vis 2005. The idea here is to write a volume rendering integral that is exactly the limit of infinitely many, infinitesimally opaque isosurfaces. The way this ends up looking like is that the volume rendering “physical space ray” ends up transformed to “data space”. Because you’re conceptually drawing infinitely many isosurfaces, it doesn’t matter whether the gradient magnitude as we traverse the ray is large or small: the final image looks the same way. So, Kraus argues this is “scale-invariant”, because the speed at which the ray traverses the data is irrelevant for the final result. This type of argument is intimately related with the work we presented at Vis 2008 and the co-area formula: when you’re switching between “physical space” and “data space”, you essentially need to divide by the gradient magnitude of the scalar field.

So, to come back to Correa and Ma’s paper. I have a sneaky suspicion that if one works with Kraus’s volume rendering integral, then it might be possible to work out the optimization in closed form (or at least something related to it). The reason I’m saying that is that the only figure for which the opacity bumps are not monotonically increasing (and almost linearly so) is the one where there’s a really large gradient in a piece of the scalar field that’s in view. It might be possible to use an approximation of this to brush transfer functions under the computational rug and simply have the users say “these are the scalars I want to see”. In fact, combine this with all the work that’s based on Gordon’s 1998 VolVis paper, and you might have a good robust automatic volume visualization tool.

The point of linearity: scary vectors are made of warm and fuzzy vectors

Now that it looks like I have a real job (more on that coming soon), it’s time to make my new bosses regret the decision by showing them how dumb I really am.

I feel like I should have known this since my freshman year in high school, but I have finally realized why people talk so much about linear algebra, and why we care about vector spaces so much in real life. I didn’t come up with this by myself – most of it came from three excellent sources: Shewchuk’s conjugate gradients paper, Strang and Borre’s “Linear Algebra, Geodesy and GPS” linear textbook, and Luenberger’s “Optimization by Vector Space Methods”. In fact, you’d be much better served if you stopped reading this post, and instead reading those books. But you’re probably reading this to laugh at me, anyway, so let’s go back to how dumb I am.

First, there are two properties of vector spaces. 1. If is in a vector space, then is also in that vector space, for every number . That is, vectors can be stretched. 2. If and are in a vector space, then so is . That is, you can add two vectors together.

Now, in linear algebra, we study vectors. But more importantly, we study things that change vectors into new vectors. One of the basic ideas is to look at the things (let’s call them transformations) that change vector linearly, that is, such that and .  Also, these transformations themselves are in vector spaces, you can add them together and scale them.

When I started thinking about vector spaces other than (and their linear transformations), my only intuition would be that “linear operators ‘don’t blow up’”. That is, if you change a vector a little bit, and you look at a linear transformation of this changed vector, then the transformation of the changed vector is not too far from the transformation of the original vector.

That is true, but it’s not the point of linear algebra and vector spaces. The really important intuition is: Break your vectors up – you know exactly what will happen to the parts!. That is, the trick of linear algebra is in applying property 2 “backwards”: think of your vector as a combination of other vectors , etc, such that . Obviously, “backwards” is a bad adjective: no one ever said that the rule applied only in one direction. However, this is how I thought about that property for the longest time. As I said, you’d all see how dumb I am.

But the cool part of this realization is it gives a great strategy for understanding linear “situations”: if you see a scary vector, break it up into cuddly vectors, and whatever understanding you get from these small vectors combines exactly back into the original vector. In particular, if you’re trying to understand what happens to a scary transformation on a scary vector , find a nice transformation that you understand, say , and define the “purely scary part” of as such that , and do the same for your vector: .

Then, linear algebra tells you that . Hopefully, you will be able to understand three of the four terms in that right side. One trick is to define the decompositions such that you know that some of these terms will become zero, or at least know that they will be small.

Once you notice this pattern, lots of mysterious (to me, at least) things in linear algebra start to make sense. The reason for the obsession of linear algebraists with eigenvectors is obvious: since a matrix simply scales its eigenvectors, if you break any vector as a sum of the eigenvectors, you can look at what a matrix does to a vector by breaking up any vector as a linear combination of the matrix eigenvectors. Then, the matrix will simply scale these pieces, and all you have to do is add the pieces to get the entire result. Eigenvectors used to seem magic, but they’re straightforward once you realize that the whole point is to split scary things into warm and fuzzy ones. I suspect most other mysterious things in linear algebra work similarly.

A fool and his money

Just heard on TV: “How would you like to lose weight FOR FREE?”. Does not eating cost money now?

Of ridiculous brands and phallic logos

Dell has been talking about a MacBook Air killer for a while, and today they unveiled the Adamo series of laptops. You see, Adamo apparently means “fall in love with”. So that’s why they decided they have to yell “DELL ADAMO LAPTOP” in all caps in the website title, because we would all fall in love with that. And who doesn’t love expressionless model zombies holding laptops in ridiculous positions? Oh, and the Adamo is also heavier and more expensive than the MacBook Air.

Is every other tech company besides Apple utterly clueless when it comes to marketing? Did Dell realize that Apple was having their iPhone event today? Did they think they’d Apple’s thunder with B&W pictures of skinny girls on designer dresses and omg-you-can-buy-matching-designer-handbags? It has to be like phallic logos, where the whole test audience goes silent thinking “Is no one else seeing the PENIS”?

(Yes, this is the post that ends a 2-month hiatus. I’ll talk about work once I have that figured out.)

OmniFocus from the command line

So I decided to out try OmniFocus, after enough recommendations from people that seem to get a lot more done than I do. It is a truly great program, and my copy of the GTD book is on its way.

There was one tiny annoyance for me which is that I spend a fair amount of time running Linux on either my laptop or my workstation, away from OmniFocus. And now that I got hooked on dumping ideas and todos via Ctrl-Option-Space, I want something similar there. OmniFocus has an option to add an extra rule to Mail.app that keeps an eye on carefully constructed emails, so I have it look for email messages from myself whose subject starts with “–omnifocus”. Python has a nice smtp library, so this all makes for a nice 5-liner I call rememberto. Here’s the (public-domain) script:

#!/usr/bin/env python
import smtplib
import sys

yourself = 'Your Name <your@email>'

msg = ("From: %sTo: %s\r\nSubject: --omnifocus %s\r\n\r\n"
% (yourself, yourself, " ".join(sys.argv[1:])))

 

smtplib.SMTP('localhost').sendmail(yourself, yourself, msg)


Make that script executable, throw it in your path, and run it from a shell. Even better, run it inside Emacs and M-! rememberto go grocery shopping!

Nokia, buy Riverbank Computing

Early last year, Nokia acquired Trolltech $153M, and there was much worry about Qt, the great GUI toolkit. The fear was Nokia would focus only on mobile devices, and cut off Qt’s open source version. In an incredibly smart move (and I have to say one I didn’t see coming), Nokia just announced it’s making Qt available under LGPL.

Think about how this would have sounded 20 years ago: Big company pays 150 mil for small company, renounces said small company’s major revenue stream by giving its product away. Rest assured that Nokia will lose Qt licensees. But as they correctly calculated, it does not matter. If Nokia wants to fight Android and the iPhone, they’d better have a decent software platform, and it better be free. $150M is chump change for them: Nokia’s market cap is around $53 billion.

A more interesting problem (for us involved with the VisTrails project, at least) is what happens with PyQt, the incredibly well-designed Python bindings for Qt. PyQt is developed by Riverbank Computing, which is really a synonym for “Phil Thompson’s one-man show”. If you pay for Qt, buying PyQt for everyone essentially costs you every sixth Qt license, which is not very much at all. But now that Qt is LGPL, what is Phil to do?

Well, he can’t really make PyQt LGPL, as he’d just sink his company. But you could argue that he can’t not make it LGPL either. For once, PyQt would be the only commercial barrier for writing commercial Python software with Qt, and I have a feeling that people would actively try to find a way around that. More importantly, with Qt being LGPL and no Python bindings to go with that, it’d be just a matter of time until someone else starts an LGPL PyQt clone. But it’s essentially impossible that any new effort will be as good as PyQt is. So, there will be fragmentation of the community and a big waste of development effort. Crucially, this outcome is bad for Nokia. If Phil sticks around by himself, chances are Nokia loses money.

So for Nokia to keep around a great set Python bindings for Qt, they just have to ensure Riverbank wants to make PyQt LGPL. And the easiest way is simply to buy the company, hire Phil Thompson, and make him PyQt dictator for life. So, Phil, it’s time to buy a new suit!

Stupidly simple depth from a single image

There’s a really simple trick for taking a picture and making it look like a miniature. Your eye has a pretty well-tuned depth-of-field detector, and it’s easy to trick it into thinking the image was taken at a different scale. Photographers have known this for a long time, and the old-school way of doing this is to exacerbate the depth-of-field effect by tilting the lens plane with respect to the film plane, like this (image from Wikipedia’s Motorrad-67):

Now, there is a simpler trick that also works pretty well. As a post-process, one can simply blur parts of the image that are closer or farther than a particular depth in the image. This is pretty effective. There’s a catch, however: notice that the people’s legs are at the same depth as their bodies, but blurred quite differently. Then the typical solution is to spend a lot of time creating a custom depth map, like described here.

I am, however, too lazy to draw my own depthmaps (and I probably couldn’t if I tried), and so I decided to code my way around this, and came up with a simple heuristic. A vertical gradient for depth almost works, and all you want to do is let the original gradient depth map “blur” in places where the image doesn’t change much. As it turns out, the cross-bilateral filter does exactly this: an edge-preserving blur of the intensities image A, using the edges of image B.

So, to compute a depthmap for your tiltshifted images, you simply run a cross-bilateral filter on a crude version of the depthmap (say, a vertical gradient) using the edges of your own image for a number of times, until it essentially converges.

To put it all together in code, you can get source code for the cross-bilateral filter at Sylvain Paris’ website, and you can use the open-source focus blur plugin for GIMP. And that’s how these came to be: Tiny Temple, Tiny Capitol.

Pretty cool for a night of hacking. Next project, Tiny Solitude.