Harald Nesland

For about a week now, I’ve been playing around with some old movies from my parents and grand parents. I wanted to digitize these old movies before they were lost forever, and for that purpose I rigged up a Goko Telecine Player and connected my digital video camera to it. This was a total failure, probably because of mismatching framerates, broken hardware and skills on operating it. Anyway, I couldn’t get the camera to record the picture correctly, at any framerate, having fixed the focus and brightness-control issues (The movies are 18 or 24 fps, and the camera is 30 fps).

I searched around on the internet for clues to this problem, and without any concrete solutions I discovered lots of other methods on digitizing this bloated movie format. My favorite method was using a flatbed scanner. I kind of laughed at this at first, but when I discovered that quite many people actually does this, and the result they were getting were great, I began to plan my own contraption of this sort.

Having all the parts I needed, I started right away.

First of all, the scan has to be automated. My scanner is really slow at high resolutions, and waiting for the scanner to finish scanning ~18 frames  takes about 1 minute and 30 seconds. Multiply this with seconds of film and you’ll get the picture. Automating the scan-process was amazingly simple with Mac OSX and Objective-C using the Image Acquisition framework. You just give it some area to scan, initializes it with the scan type you want (transmissive, colored), and you’re off to go. It even handles filenames and increments them, so just fire and forget.

The next problem was to actually move the film forward after each scan. For this I used a dc-motor I had laying around, and connected this to a Phidgets Motor Controller which is USB-based and really easy to use (like four C-functions, and it runs with no fuzz). A standard 8mm film reel is mounted to the motor with a couple of screws and some glue :) So after every scan, I ran the motor at a given speed for about a second and scanned again (rinse, repeat). I fine tuned these numbers to how many frames I wanted to pass through. I could only fit ~16-17 frames in one scan due to a design flaw in my scanner.

Another problem was to keep the film in an exact path and completely horizontal. This is more of a physical problem, than a software problem, and I solved it by gluing a couple of guides the film could go through on a plexi-glass that I then layed on the flatbed.

8mm movie reels are mounted on the old telecine player, just because it was practical at the time being, and the movie goes from there to the dc-motor via guides on the scanner.

Now that the software is able to scan and move the film, I can let it work through the night. It takes about 6-7 hours to scan a 2-3 minute long movie. The scanner needs to adjust its scanhead between every scan, and this takes a few seconds. Really annoying. The result is about 250 images at 25MB each (PNG, 4800 dpi). These images contains ~16 frames, and I needed to split these frames to separate files. After each scan, I also check if >20% of the image is colored, that is, not completely white (by a given threshold). If 80% of the scanned image is white, I stop the process and the film scan is complete. This prevents the scanner keep running without any film to scan ;)

This frames are pretty randomly placed within these slides, so the position of each frame has to be calculated. There is many examples and sample code for doing this, and many uses the Canny edge detection algorithm. The “sprocket” (the rectangle on the side of each frame) on the film is very highlighted on the scans, and therefor very easy to detect. I didn’t use this algorithm, I based my detection completely on the color brightness of one row of pixels at a given x-coordinate. By doing this I could detect the beginning and ending of a sprocket, and knowing this is placed at the center of each frame (Super8 only, on legacy 8mm the sprocket has a different position, and size for that matter), I knew the height of each frame. The width is constant, and no problem for my software. I also did some sanitizing of frame sizes, to skip half-frames and such.

Having all the frames ready in incremental numbers, I fed them to QuickTime’s “Open Image Sequence”, and there the movie was ready to play. To finish I clicked export and tweaked a coloring filter to do some easy enhancing, and the result was a pretty nice 640×480 movie, and a lot better than what I could expect from the telecine player I rigged at first.

The process is tedious, but when automated it’s doable. QuickTime does a great job on putting the frames together.

Here’s a screenshot of my Mac-application that does all the magic:

It renders a preview after each scan, this has no practical purpose, but it looks cool! I hope to release the source code soon after cleanups and memleak-fixes (eats a good chunk of 2GB on a good night ;).

Oh, and here is a screenshot of a rendered movie. I’ll upload a sample movie as soon as I convert one to Flash/FLV/Ogg Theora or whatever you kids manage to play. I get too many complaints on QuickTime .mov-files :-)

This is without any filtering and the frame cut is a bit bigger than necessary.

If you like this project, check out more details around the movie format, build methods, code etc on these links:

• Flatbed Telecine
• Richard Kinch
• Jim Carroll

Thanks to these guys this project became a success. Pictures of the configuration is coming also, for now this video will have to do:

This is a video from the early stages of the project, before I had a guide for the film, thus getting scewed frames. I will update this soon.

In my spare time from writing iPhone apps or working at Nordicom, I am doing some home automation stuff. My garage door is opened and closed by a motor, which is controlled by a radio-relay and a remote control. This setup is very old and the remote is big and cumbersome. I took a look inside the door opener and figured out the different parts fairly easily. My plan is to add an additional relay which is connected to an Arduino-board. This Arduino also has an RF-receiver which listens to an RF-transmitter inside the house. The RF-transmitter receives signal from my home server, and the signal may be triggered by basically anything. At first I’ll write an iPhone app that lets me get rid of the big cumbersome remote control, and later I might write some software for automatic closing of the door. For instance auto-close if nothing is moving inside or nearby, or is blocking the door.  

The garage-arduino will also have a signal from my postbox. Just a basic switch that triggers a signal when somebody opens it. It’s nice to know when mail arrives etc. I might also add a temperature sensor, and other movement sensors. This requires an additional transmitter/receiver, and might require some more planning. I should probably go for Xbee on both ends.

With this setup I’ll be able to open and close the garage door from anywhere in the world as long both me and my house are connected to the Internet.

Okay, long title but it’s for teh google. For some time now I’ve been trying to get this PC-card to work on my Mac Pro. It won’t out of the box, but with some adjustments to the cards BIOS/ROM you can get it working.

The first thing you need to do is get your current bios from the card. This can be achieved by using GPU-Z on Windows, or ATIFLASH.EXE from DOS (FreeDOS, Ultimate Boot CD). With GPU-Z you just click the chip-icon and it saves the RV770.BIN file. NOTE: The size has to be 128K. If you’re getting a 64K file, this means the dump didn’t finish or the utility didn’t understand to dump the whole ROM.

Now you’ll need to modify this bios by adding the required EFI-firmware. For this you need an actual Mac 4870-romfile. Like this one.

Then we need to extract the EFI-parts of this romfile. This can be done with the dd-util that is distributed with every Mac, Linux and BSD desktop :)

dd if=mac4870.rom of=efi.part bs=1 skip=63488 count=49152

Then we figure out the size of the blocks.

blocknum=$(printf %d "'`dd if=RV770.BIN bs=1 skip=2 count=1 2>/dev/null`")
size=$(($blocknum * 512))

The $size variable will then be used in the next dd.

dd if=efi.part of=RV770.BIN bs=$size seek=1 conv=notrunc

Now the EFI-parts has been added. We then need to adjust the final rom before use with a Python script written by “pipomolo42″.

python fixrom.py RV770.BIN RV770.BIN

First parameter is the in-file, the second is the out-file.

Now the RV770.BIN is ready to be flashed to your card. This can be either done from DOS with ATIFLASH.EXE (atiflash.exe -p -fs -fp 0 RV770.BIN) or with some Apple-tools if you want to do this from OSX.

So, for OSX flashing you’ll need iMac Graphics Update 1.0.2 and Pacifist. We’ll use Pacifist to extract ATIROMFlasher.kext and ATIFacelessFlash.app.

You might want to remove all .IMG files in ATIFacelessFlash.app/Contents/Resources/ before you continue. Then you have to add your custom made RV770.BIN to this directory. When done, execute the following commands from a terminal.

# This will load the interface for flashing ati-cards.
sudo kextload ATIROMFlasher.kext/

# This will do the actual flasshing
sudo open ATIFacelessFlash.app/

# And this will unload the flashing extension.
sudo kextunload ATIROMFlasher.kext/

You’ll notice an icon appearing in the Dock while flashing, and it silently disappears when done. When it disappears, reboot your Mac and the card should work.

Thanks to all contributors of the MacRumors forum and to Boeglin.

Tweaked the site a bit, it isn’t really used that much, so I’m adding components to what I use more, like SmugMug and Twitter.

Also added a new theme based on Witcher World. Removed the childish glowing butterflies and added some black forest. It’s nice.

About 2200 frames at 23 fps. Taken through a window which explains random reflections and dirt :)

After rewriting VMBT to use Internet Explorer for its chat-view, I’ve discovered a few snags. The component is loaded in to the .NET via COM, and all content is added through the DOM. Using a web browser for this view opened a lot of possibilities. The most important one is JavaScript. With the JavaScript we also have access to methods exposed from .NET, which mean I can interact with the application in the “web site”. To make things a bit more simple, I loaded the jQuery framework to my component. This is when the trouble was starting.

For some reason IE couldn’t read the jquery.js-file from “file://c:\blabla\installationpath\data\jquery.js” unless the file was copied there and not “installed” by the installation software (Nullsoft Install System). At first I thought it might be due to some corruption, but after seeing the file was identical to the source file I understood it had to be an access problem. However, I was unable to verify this with the ACL-management provided by Windows, there were no differences between a copy that was working and one that wasn’t. It’s a really stupid problem, and I’ve still no solutions for it.

So to be able to debug this a bit further, I decided to throw in the latest Internet Explorer (8) with a bunch of updates etc. This failed miserably since now the whole problem disappeared altogether.

I can’t find any information about this problem, the IE-component doesn’t say anything when it can’t open files and it probably requires great, and unheard of, skills of managing Windows.

My best solution right now is to upgrade to the latest Internet Explorer if you haven’t already done so. (There isn’t really any good reason in this world to either USE the browser or for you to NOT upgrade it. So go upgrade it, and use Firefox instead :))

This is great fun :-)

Finally the fact that the “cryptography” used in Brønnøysundregistrene has been broken has been made public. Digi.no has an article about it in Norwegian. The first time I came across this “cryptography” was a couple of years ago. Strange no-one else talked about it before now.

Anyway, the data being obfuscated is the national identity numbers for owners and contact persons in companies. There is no reason for that data being available, it has no use and is most likely a technical mishap :-)

UPDATE: I just got a call from some people at Brønnøysundregistrene, they asked me to remove this disclosure paragraph. So well, it’s gone. Sorry.

We came across this obfuscation when we were porting the database from Brønnøysund to another database system (MS Access doesn’t really scale, contrary to common belief..). Most fields were obfuscated, and the software for reading the database is useless :-)

They should have used Blowfish instead. That would at least take one Morris O’Brian to crack! Because Bruce Schneier has a backdoor in the encryption algorithm!

Finally I can try out the 3D-plugin for Sesam Maps. This is actually pretty cool. Got lots of nice pictures from Kristiansand too. View the town from different angles.rn

rn

rnrnVisit Sesam! (I can’t link anything because Safari 4 messes with some z-ordering in Wordpress so the link-dialog appears below the shadow or something.. stupid webbrowser.. also, the plugin doesn’t work anymore so I can’t really link something useful anyway :)