Tuesday, July 20, 2010

Installing opencv 2.0.0 through macports... Piece of cake or Pain and misery?

ARRGH! Okay now that out of my system... I hope someone finds this post useful.


"If you encounter errors, try installing its dependents with +universal whenever possible."

Great... but what if that doesn't solve your problem.

Mac OS 10.5.8, Macports 1.9.1, OpenCV 2.0.0
Perhaps this is a naive approach, I've since learned about checking "port variants opencv" so perhaps "port variants lame" would have turned up a helpful clue... but this is what I did to solve my issues. Take it or leave it.

My first error:

:info:build xmm_quantize_sub.c:37:23: error: xmmintrin.h: No such file or directory

If this error looks familiar it's because LAME didn't build (LAME 3.98.4).

"If I run make immediately after configure, it fails. What I have to do
to make successfully is to first comment out the following line in


Taken From http://www.opensource-archive.org/archive/index.php/t-88245.html

Tried even setting the define to 0 but that didn't work, so commenting it out may be your only option. Let's try building opencv again...

AND... Ka-blamo... another error. This ones worse than the first. It seems to be with ORC (formerly liboil) 0.4.5

It has no idea what the function get_cpuid is, any why should it? It's supposed to know better thanks to ifdef __APPLE__, right?

Look at the bottom of orccpu-x86.c (in the macports work directory).
//orc_cpu_detect_kernel_support ();

#ifdef USE_I386_CPUID
return orc_mmx_detect_cpuid ();

Oops, if I'm reading this right then regardless of whether it's been defined Apple it's still going looking for the get_cpuid function because we're on an intel Mac. Naughty, naughty. Let's comment those out and cross our fingers.

orc_mmx_get_cpu_flags(void) { //orc_cpu_detect_kernel_support (); #ifdef USE_I386_CPUID return orc_mmx_detect_cpuid ();

There's another one in the matching function orc_sse_get_cpu_flags(void) too. Make sure you get both and "orc" will compile.

This post likely explains why the error may not appear for some people (looks like it depends on which assembly compiler you are using, but I'm guessing that this is a bonafide bug).:

Okay, so far so good, ffmpeg is the last to go... Totally expecting it to crash and burn.

Oh, okay, that worked. It's building and installing opencv now. Could I possibly be that lucky? Guess I'll have to build a project in Xcode and find out.

Thursday, July 8, 2010

Banff CAVE redux

I was fortunate enough to help restore the Banff CAVE to a functioning state. We used the Cosm Library for Max/MSP to create our own series of cave.* objects for Max. Those can be downloaded in their rough form from www.futurecinema.ca/arlab. Several modifications have to be made to use them in your own cave like environment, mainly the windows have to be aligned to work with the projectors you are using. You have to enable/disable the dual windows manually that are being used for stereo. And you will have to repurpose the cave.send and cave.jit.send patches so they are hard coded with the IP of your destination machines (and new ports may have to be added depending on the number of machines you are using). We had two renderers and one server.

Saturday, April 17, 2010

Gremlins are back - need proof?

Some strange things have been happening to the technonolgy around me.
Of course, I blame gremlins...

Friday, April 2, 2010

"So close and yet..."

Hmmm... The good news or the bad news? Well here's both.

As you can see, the ladybug2 can now talk directly to Max... But it's green and unhappy. There are two major problems, one which I couldn't have foreseen, the other I'm an idiot for not considering.

First: We were lucky enough not to have the Bayer filters included in Libdc1394v2, to try and decode the RGGB that the ladybug is outputting but as you see it doesn't work as expected. Our theory is that the code is expecting the image to be upright, but as you can see, our image directly out of memory is 90ยบ from where it should be. So why don't we just rotate the image before processing? Well, as it is we are copying the matrix once, from memory, to the outlet. This image is huge, a whopping 4608x1024. That's 6x768x1024. So of course that brings me to the second problem. Under no circumstances have I ever been amazed with the framerate of an incoming image in Max at 1024x768. Let alone 6 of them simultaneously. So is this even a good idea? Perhaps there's just too much visual information to process to be useful at all. Not one to give up too easily, I may have another solution. If we output the raw image into a jit.slab and crunch it all on the GPU (which is what they do at Point Grey if I'm not mistaken anyways), then maybe we can get the performance up to something halfway decent. Definitely open to suggestions.

Finally something to contribute to the Max Community after a long time. Thanks to Rob and Andrei from York and Rand at Intersense. Download at futurecinema.ca/arlab

Follow the instructions in the top corner of the .maxhelp patch to get the dylib installed and get you up and running. Sorry but I think the object only works on OS X 10.5 (Leopard) and up.

Wednesday, March 3, 2010

Looking Back at Almost perfect...

Hey I'm on TV.... ;)

Ladybug Woes on a Mac


Been working with the Libdc1394 version 2 library thanks to a tip (thanks Louis!) and am trying to get the ladybug working with Max/MSP. The OSX port of Libdc seems fine until you try to capture a series of images and I get a "bus Error". Tried posting to the forums, no luck, but I solved it, it seems there's an error in the "BASENAME" string in the Sprintf function. If you change:


Tah-Dah, it works (though it drops all your frames in your current folder... sorry about that). Will try and figure out how to get that running soon, and then, on to getting it running with Max/MSP.