drewp

David and I brought light9 back to life again a few weeks ago to run lights and sound for an annual dance show.

Each year we put a little bit of time into the code and then design and run a show over a weekend. Then we don't think about the code for hundreds of days, which leads to time-capsule notes to ourselves for the next year. It's a little disturbing to think about the future of a code project when it has the property that each chunk of development takes 1% of your life to complete.

This year, the notes have a bunch of small technical fixes, but I wish we could make some big changes that really improve our productivity. The bottleneck occurs when the dancers are rehearsing a song and we're trying to design and test lighting effects at the same time. We only see each song a few times, so even half a second lost to 'using the software' is a concern. There need to be actions like "that looks cool, remember it", "that was right, but a bit too late-- put it on a list of things to review with music later", "make the light animation 10% busier", "give me a random, contrasting look right this instant so I can fade to it (and I'll fix up the exact look later)". These actions need to be run from either of our computers.

There are other actions that would be helpful to run remotely. Sometimes I'm up on a ladder and I need light b35 turned on and then the other two blue lights faded up and down so I can see how b35 fits in with them. Dave can do this pretty easily from the booth, but it would be a better use of his time if he was in the audience planning out the looks we're trying to acheve. Maybe I can manage to press buttons on my cell phone, or maybe we can get some voicerec working.

Like many other data-editing tools, the light9 software uses names for various entities. I don't mind typing the names for songs, for example, but it's pretty poor that I have to name the things that I want to fade up and down during a song. We end up with names like "slcross", "green", "cs1", "edge", "bpurpleall", "centercircle", etc. I'm typing those (and reading/decoding them) while a song is being rehearsed, which is the most sensitive time of all! I want to move toward images, either captured at the moment we make the look, or synthesized from photos of each individual theater light (which is easier than it sounds [my project] [Ian's project]).

I also have most of the data in RDF, which should open us up to better sharing and syncing between apps. Right now I still read .n3 files from the filesystem, so there's no improvement in functionality. I like Sesame, so I thought I'd put my data in there and use some messaging service to send pings between the apps when things change. But the Open Anzo RDF store may have figured out that notification stuff already, so I'm eager to look into it some more.

Photos of our setup in the theater lighting booth

Code repository and commit log

Original problem: I want to combine images of individual theater lights to simulate what it would look like if they were turned on in some combination of brightnesses. That's fine, but when my input image has a washed out area at the hotspot of the light, 50% of that image will not be correct. There will be a gray splotch in the shape of the hotspot. Here's a demo using a desklamp in my room:

Solution: Use High Dynamic Range images that contain relative brightnesses even inside a washed-out area. With a low-end camera like mine, I can take multiple exposures of the scene and then reassemble them automatically into an HDR image. Tools that might be able to do this include cinepaint, HDR Shop, and qtpfsgui. Then when I want to see a particular mix of lights, I add my per-light HDR images with the appropriate scale factors and clip the result to white. The result should be like I took a real photo of that light combination.

New problem: Unless my input images (HDR or not) are all calibrated to the same brightness scale, my resulting image will be incorrect. E.g. if light1 is dim and light2 is bright, my simple camera will probably auto-expose light1 to be brighter than it really is and vice versa on light2. My resulting images will be incorrectly low-contrast-- each light will have been adjusted towards the middle. If I use my digital camera to take the photos, I might be able to get some EXIF correction data. But if I use my laptop webcam, I don't think I can ever learn the auto-adjustment level. It would be nice to know the scale factor of each of the input images so we can normalize them before adding them.

New solution: After taking the per-light images, take another picture that has all the lights on (or a few pics of various known combos). Then solve for the scale factors on each light's image that would lead to the measured combo image. Each pixel in the allLights image is a combination like this:

scale1*light1(x,y) + scale2*light2(x,y) + ... = scaleAll*allLights(x,y)

There are a lot more pixels in each image than there are unknown scale factors, so this should be solvable. Once we figure out the scale factors, we can start making accurate sums of the input images.