Apr 21, 2012
Bret Victor - Inventing on Principle from CUSEC on Vimeo.
After spending many years working on C code that pretty much directly manipulates hardware, I stepped into the world of Python and Javascript, which has definitely shown me a lot on the unexplored potential of programming languages. I admit I had failed to see the potential of interpreted languages early on. My experiences with Basic in the 80s left me with only the idea that they were slow and clunky, compared to compile code which ran orders of magnitudes faster. Working with the Turing and Prolog interpreters didn't give me much insight either - I just felt like I would be more efficient working with a real editor than the stupid command line.
It wasn't until I started working with Python and Javascript, where it really struck me that I could put a breakpoint in my code, have it break on execution, and just run any new code from the interpreter console. That's changed the way I write code entirely. At that moment, it felt like the possibilities were endless... but after a little while, the new way of doing things also became business as usual. Bret Victor obviously didn't stop there, but kept driving with "how can this be even more useful?".
I'm glad to see that this video has already spawned off a project to make it reality.
http://www.kickstarter.com/projects/306316578/light-table
This is so cool!
Feb 24, 2012
Graphics on a Tesla C2070
I spent pretty much an entire day trying to figure out how to get it to run as a graphics card. In the back of my mind, I knew I had done it before, but just couldn't remember how. I spent ages on live chat with Nvidia customer support. I knew better than to trust first line support, and they were indeed a waste of time. I eventually eked the memory back into existence.
In the driver install folder (typically C:\Program Files\NVIDIA Corporation\NVSMI" run the command "nvidia-smi -dm 0". This sets the driver to run in graphics mode, treating your Tesla card as a graphics card.
There's a number of reasons NVIDIA has two separate driver modes. Graphics processing tasks have a maximum time limit of 2 seconds, after which Windows thinks the GPU has hung, and resets it. If you have some high performance task running, say a raytracing operation that takes a minute, this may fail. Running in a pure compute mode avoids this problem, but also disables the card from appearing as a graphics device.
Feb 8, 2012
Progress.
I suspect those who are afraid, aren't really looking hard enough for those opportunities.
PressPausePlay from House of Radon on Vimeo.
Jan 8, 2012
Mmmm Fat.
I tried making it over the holidays. The first challenge was finding a recipe. Searching for combinations of "shanghai pork shoulder leg hock" let me to four similar recipes of varying complication (note: "ti pang" seems to be the most common spelling online). I then decided to screw with the recipes by using my mom's new thermal vacuum pot using some fancy low-temperature cooking technique. Or so I imagined.
I tried the recipe twice, the results were... not great. Perfectly edible, but far from perfect. The great thing about fatty, tough meats is that if you cook them long enough the flavorful fat will make up for all your errors, so even when it's bad, it's reasonably good. The four recipes had varying cooking times, from 2-12 hours. Most involved simmering/braising, though Albertitto's recipe called for an interesting immersed steaming technique. Two of the recipes called for refrigerating overnight.
Instead of using 15lb pork shoulder, I used a 2lb pork hock. That was probably my first mistake, but the pork hock was far more manageable, and I probably would have had leftovers like crazy with the 15lb piece. Also, pork hock is inexpensive. Instead of simmering for hours, I decided to give the vacuum pot a try. The word vacuum sounds fancy, and evokes images of sous vide. In reality, it's really just a giant thermos. The contents of the pot are not under vacuum - the pot has a vacuum insulating wall. You would cook something normally on the stove, and then stick it in the pot. The retained heat will continue cooking the food for hours as it cools - very slowly.
On my first attempt, I followed typical thermal vacuum instructions, bring the water inside to a boil, then letting it cook in the vacuum pot for four hours. At the end the meat was a light tea colour, hardly the rich colour I expected. I refrigerated overnight. The meat had gotten darker. One big difference with vacuum pot cooking is that the fluid doesn't evaporate. I ended up simmering for a couple of hours until the sauce reduced. The meat darkened during the simmering process. Overall the flavour was right, the meat fell off the bone, but was a bit on the dry side. Although soft, the skin wasn't at the desired jelly-like consistency, but was chewier, though some people might like that.
I thought it might have been that the boiling temperature was too high. On my second attempt, I tried lower temperatures. I heated the pork/sauce to about 175F, but let it cool to 160F before I stuck it in the pot. When I took it out 4 hours later, it had dropped to about 138F. I heated it back up to 160F and gave it another 4 hours. When I pulled the pork out, and shoved a meat thermometer in, it was still far stiffer than it should have been. Again, I had to simmer the sauce down, which did enough to tenderize the meat to an edible state. The result the second time wasn't much better than the first.
My suspicion is that I'd either need the low temperature going for much longer than 8 hours... perhaps 24 hours or more, which seems like a lot of work since I would need to reheat the pot every few hours, and make sure it doesn't drop in to the bacterial danger zone below 130F. The simmering process seemed to do far more in tenderizing the meat than the slow cooking. I'll have to try out the 24 hour version sometime... as well as the simple braise and the steaming method. After I've worked off this year's calories.
They should make a movie out of this.
Jan 3, 2012
No Quadrantids.
Off to bed I guess.
Nov 21, 2011
Earth from Space.
Earth | Time Lapse View from Space, Fly Over | NASA, ISS from Michael König on Vimeo.
Oct 5, 2011
Capture One 6.3: A Performance Review
So it's been about a month since I've gotten back, and I've barely touched my pictures in that time. I decided finally to sit down and give Capture One 6 a shot, since I switched over to Lightroom a couple of years ago. The software is already up to version 6.3. I used the trial version, so I could check out Pro. I was curious about some of he features, especially the advanced noise reduction and local adjustments. I'm running on Windows 7 SP1 64-bit, on a Core i7 930 with 12GB of RAM, and a motley assortment of hard disks. I tried using both a GF106 (GeForce GTS450 or Quadro 2000) as well as a GF100 (GeForce GTX 470 or Quadro 6000). I'm playing with full resolution RAW images shot on a Canon 5D MarkII. While I was pretty happy with C1 versions 2 and 3 for dealing with images from my Rebel and Rebel XTi on an old Athlon system, the huge images from the 5DMk2 has put some annoying lag into the workflow, that never went away even after upgrading to the i7.
OpenCL Benefits
C1 allows you to turn on and off OpenCL support in the Edit\Preferences dialog. There's a setting for OpenCL, either Auto or Never (this setting doesn't appear if your system doesn't have an OpenCL driver). Other than the setting, there's no other indicator that OpenCL is being used. There's information in a Phase One knowledgebase article on when OpenCL is used, it's pretty accurate, but not very detailed.
After poking around with the OpenCL setting enabled/disabled, I figured OpenCL is only used for processing the pixels onscreen when viewing a RAW file. This is pretty limited, but it does provide some noticeable benefits that do impact my workflow.
1. the view updates much quicker when switching between images, particularly when zoomed in
2. the view updates much qucker when making adjustments, particularly when zoomed in
*1 Given that these were all visual changes, it was difficult to give any benchmark measurements. Situation 1 was where I noticed the most measurable differences. When switching from one image to another on CPU only, the new image would load in very blurry, then get less blurry, then crisp. There was also about a 0.5 second delay before the image changed at all, but that happened with both CPU and GPU, so I'm going to ignore that in the comparision. My rough attempts at measuring the time with a stopwatch makes it look like this: new image appears very blurry -> 0.5 seconds -> less blurry -> 1 second -> crisp, so it would take almost 2 seconds every time I changed from one image to the next. It gets painful if you're sorting through 150 images after some sort of shoot. The first 0.5 second delay after the keypress was there on every GPU, so I'm going to ignore that, and focus on the first delay after the image appears, and the second delay when it becomes clear.
GPU behavior looked the same, but upon closer inspection it looks liek the pipeline was different. Instead of going from "very blurry"->"less blurry"->crisp, it went through a "blurry"->"crisp"->"denoised/sharpened" stages. It was barely any time at all on either GPU to get from blurry to crisp. I'll say 0.2 seconds. Additionally, the final "denoise/sharpen" stage seemed to vary a bit depending on the zoom level. Initially I thought the speed depended on the GPU, but then I noticed that in zoom levels > 100%, it looked like it would do some sort of denoise, while if the zoom < 100%, it would sharpen. The sharpen (at low zoom) would take about 1 second on both GPUs (I'm guessing it was actually performed on the CPU). The denoise seemed to take about 0.5 second on the GF106, and was nearly instantaneous on the GF100.
For Zoom < 100
| Processor | Time to Clear Image | Total time for Final Image (including initial delay) |
| CPU | 1.8 | 2.3 |
| GF106 | 0.2 | 2 |
| GF100 | 0.2 | 2 |
For Zoom > 100
| Processor | Time to Clear Image | Total time for Final Image (including initial delay) |
| CPU | 1 | 1.5 |
| GF106 | 0.2 | 1 |
| GF100 | 0.2 | 0.3 |
*2 When making adjustments with the sliders, it was noticeably smoother on the GPUs than the CPU, though even the GPU wasn't perfectly smooth. It also depended on the setting. For example, adjusting Exposure was reasonably smooth on the CPU, and wasn't too much smoother on the GPU. The Moire slider though, which was completely un-smooth on the CPU, showed a marked difference. The biggest difference however, was that when zoomed in, the CPU version of Exposure, Curves, and Colour would use the preview sized image while adjusting. Once you move the slider, the image would get downsampled and blurry to show the adjustments, and then come back into focus. The GPU version would remain in focus the whole time. The GF100 was a bit smoother than the GF106. This isn't something you'd notice initially, since it just seems like the way it ought to be. But if you go back to the CPU version, it's horrible.
Things that don't improve with OpenCL
For all the improvements, there are a lot of things that don't improve, and really reduce the effectiveness of the OpenCL implementation. As I've already mentioned, it looks like there's a CPU sharpening pass that slows down the image rendering. Other noticeable items are:
- Speed depends on whether the image is cached. The numbers above are the best case. If you switch to an image that isn't cached, it could take a few seconds to read from disk, regardless of your CPU or GPU. This actually happens a lot, so you don't really get the optimized speeds listed above unless you're going back and forth between a set of images.
- JPEGs don't go through the GPU pipeline, so if you happen to have JPEG thumbnails, sorting through them will slow you down, even though scrolling through RAWs is now faster.
- Zooming in isn't sped up, you still see a bunch of pixelated pixels for half a second before the proper pixels are displayed.
- Panning isn't sped up, so when you move the image over, you get a bunch of new pixelated pixels for half a second before the proper pixels are displayed.
- Final rendering doesn't take advantage of the GPU. You might get a slight improvement if they're going on in the background, since the CPU is a little less busy with the UI.
Shoehorned in
As I mentioned initially, it looks like Phase One took whatever was visible onscreen, and sped up the processing of that bitmap using OpenCL. This makes sense given that they have an existing codebase, This means they don't have to start from scratch, and they can reuse existing functions like their CPU sharpening algorithm. The problem is that their original design is based on the fact that processing many pixels is processor intensive, so they optimize by only processing the pixels onscreen. Trying to shim the GPU using their existing design is rather limiting. They're most likely sending the visible bitmap to the GPU for OpenCL processing, which is fast. Then I suspect they're copying back down to system memory so that it can fit right back into their existing pipeline and have the CPU finish whatever work it needed to do. There's a few items that are sped up, but they're far from perfect, and in the grand scheme of things, they perceived improvement is just not that spectacular given the bottlenecks.
The ideal design to take full advantage of the GPU would be to upload the entire image to video memory, and manipulate it in video memory using the GPU, and display it, without copying it back down to system memory. With GPU memories being typically 512MB or 1GB+ these days, it should be a problem to fit multiple 20MP images in video memory. Making copies of the images is much faster on the GPU as well, since video memory tends to be 3-10x as fast as system memory. The result would be much smoother performance in adjustments, as well as smooth zooming and panning.
The main drawback, and I suspect the reason Phase One didn't go down this route, is that it requires rewriting the entire application. All the complicated image processing algorithms would need to be rewritten. Not only that but they'd need to maintain both pipelines. It's hard to argue against this. While technically far superior, this would mean twice the work. Phase One would need twice the sales to justify it. If C1 was fully GPU accelerated, I'd probably switch to it over Lightroom. One strong argument is that an i3 laptop with a midrange GPU could outperform a much more expensive i7 system. It's quite possible that C1 could take a sizeable share of the Lightroom market if their app is that much faster and smoother.
They could also potentially support one pipeline with OpenCL (or CUDA), and rely on CPU implmentations when the user does not have a GPU.
A third, weak argument to design C1 around GPU processing is that the CPUs on forthcoming Wiin8 tablet PCs will be rather weak. A GPU solution would far smoother, especially for allowing the user to drag the image around with their fingertips. A RAW editing app on a tablet would be great, but I suspect it would HAVE to be GPU oriented. Problem is none of the tablet GPUs are particularly programmable yet. We'd probably have to wait another generation - I suspect late 2012, and at this point I wouldn't know whether CUDA, OpenCL or DirectX 12 would be the way to go.
Other Bottlenecks
The other major bottleneck in C1 is the disk while rendering final images. The rendering is done purely on CPU. Tests across the multiple GPUs showed the same time, roughly 3:20 for 30 RAWs from a 5D MarkII. On a quad core i7, the CPU cycled between 0-100% load. The average was only maybe 50%. I suspected the bottleneck was my disk, so I tried using two disks, using one as the source, and the other as the destination. That made no difference. What I did notice was that C1 was writing to 8 output JPEGs at once. Most likely, the thrashing caused by this was limiting performance. The disk output was pretty slow, maybe 1-5MB/s, probably due to the thrashing. Phase One may be relying on their customers to purchase SSDs or use RAID arrays, but if they queued up their disk writes, it could potentially halve their rendering time on quad-core CPUs.
As a side note, I probably bought the wrong components on my PC. With a quad core i7 and 12GB of RAM, I rarely saturate the CPU (only when compiling using MSVC), or the RAM (only when running multiple VMs). Very few apps seem to be optimized for a fast CPU and lots of RAM. I had though that the extra RAM would mean fewer disk accesses, but there's still many cases (like both C1 and Lightroom) where I'm disk bound, with plenty of free memory.
Other notes on C1
Capture One LE was my first RAW workflow application, and I'm probably biased towards it because of that. I never fully got used to Lightroom's model with different modes, and the Lightroom's export to JPEG always felt a little weird, since the UI features rendering for print or web, and I never do either. When C1 was redesigned with the new .NET based UI, there were a number of things that turned me off, and I eventually switched over to Lightroom. I always organized my RAW files in folders by date. I hated the way C1 would put its working folder into every one of my folders. I loved the way the older C1 let me put all my final output files as subfolders of the image folders - now this seems to be available in the Pro version only. I find this seriously annoying.
In addition to those annoyances, the slowness of C1, the poor noise reduction, and the spot healing tool led me over to Lightroom. The OpenCL support has definitely improved the performance. The noise reduction seems much improved as well, though I haven't played with it enough to really judge it against Lightroom 3. There's a new spot removal tool that works pretty well. They've also added in keystone correction, which is only in the Pro version.
Right now I'm quite happy to use C1 Pro over LR3. It's $399 though, which is pretty steep unless it's discounted. There's a handful of features that I'd use in the Pro over Express - the output folder management, along with keystone correction, and maybe RGB curves. If they could come up with a third intermediate version that would match the LR3 feature set, that'd be perfect.
Sep 9, 2011
Canada vs. The World
| Android | iOS | RIM | Symbian | |
| Global | 43% | 18% | 12% | 22% |
| Canada | 12% | 31% | 42% | 6.4% |
| US | 36% | 26% | 21% | 1.9% |
I assume the high adoption for Android and Symbian globally is because cheaper phones are more common in less wealthy countries. Canadians must be pretty well off, since they love their iPhones, and hate on Android. I'm not sure if the RIM-love is patriotism, deals between RIM and Bell/Rogers, or some kinda of duty implication that benefits RIM handsets. (US/Canada data from Comscore, Global data from Gartner)
Aug 29, 2011
Road Trip Day 11
Aug 28, 2011
Road Trip Day 10
Road Trip Day 9
Aug 27, 2011
Road Trip Day 8
Road Trip Day 7
Aug 24, 2011
Road Trip Day 6
Aug 22, 2011
Road Trip Day 4
Road Trip Day 3
Road Trip Day 2
Aug 21, 2011
Road Trip Day 1
I had initially planned to leave San Francisco on 8/16, but I discovered later that Body Language was going to be in town on the 18th. I delayed the start date by a few days, which ended up being perfect, since it gave me a few days to rest for the drive after a hectic weekend.
Viv most generously hosted me, since I already moved out of my apartment. Hence we were well rested as we left on the morning of the 19th. It was a few hours after I had originally planned to leave; I had brought the car in for an oil change the day before, but they ended up replacing the water pump and a valve gasket as well.
We left Burlingame around 10am and took a quick stop for breakfast in Santa Clara, and then drove on to Carmel. It was cloudy all morning, but fortunately skies were clear by the time we got to the beach. We passed through the town pretty quickly, but took some stops to admire the beach and some of the fancy oceanfront properties. We also stopped by the Carmel Mission, which I had never noticed before. It had a satisfying historic feel to the museum in the restored building. Definitely worth visiting on a trip to Carmel.
Next down the route was Big Sur. We only stopped a few times for photos, but the beauty was constant on a wonderful drive. We stopped for a moment also in San Simeon to see the elephant seals. I had read about them ages ago, but it was the first time seeing the blubbery giants. I could see that it wasn't really worth a trip just for the seals though. They mostly just lie there, and scratch themselves lazily occasionally.
We also made a quick stop at the Hearst Castle visitor center. It was almost 4, and the tours were already done for the day. I didn't realize that the visitor center was miles away from the actual buildings and you could only see it from afar, perched at the top of a distant hill. It did give the estate a sense of grandeur, but wasn't really interesting enough to make me want to repeat the drive.
The next stop was supposed to be the Griffith Observatory in LA. It was hard to tell what the quickest route would be. We stopped off at the Main St. Grill in Cambria to grab a quick late lunch. Sinyee had recommended it almost 10 years ago, and the fat dripping BBQ tri-tip sandwich met expectations.
We took the route through Paso Robles, passing the vast field of oil wells at Lost Hills. It was a bit of a detour, and took about an hour and a half to get back to the I5, but the route was mostly straight and clear. We made it to the Observatory around 9, an hour and a half late for sunset, but the place was still open.
You have to drive past the Greek Theater on the way up. Death Cab for Cutie was playing that night, but the concert had already started and there wasn't too much traffic, though the Observatory parking lot was packed.
After checking out the view of LA, we swung by Son of a Gun for dinner. It was featured in Bon Appetit the previous week, but surprisingly there was no line when we arrived; I guess we were late enough. The smoked mahi dip wasn't bad, but far less interesting than the Bon Appetit article might have suggested. It reminded me of a tuna sandwich filling, with the addition of a nice smokiness. The alligator schnitzel, crisp and thin, exceeded expectations. There was no fishy flavour, it could have been mistaken for tender pork. The lobster roll compared favorably to the one I just tried a few days before at the Old Port Lobster Shack in Redwood City, though this one was about 1/3 the size, and 1/3 the price. I preferred the "naked", mayo-free version at Old Port, but the SoaG roll was better toasted and buttered.
The lime frozen yogurt though, was fantastic. Hands down best $5 dessert with the sweet meringue and graham crunch on the side. I have to say this was better than the dessert at Benu the night before, and that meal cost 4x as much (though that meal was also great).