A fork of OpenCV 2.0 can be found at https://code.google.com/p/opencv-cocoa/ which has both the Cocoa and Quicktime updates. This is completely tested so use it with caution. Any help and suggestions are greatly appreciated.

Because Cocoa functions strictly inside a MVC framework there is a small change that you must make at initializing HighGUI that is found here. It boils down to the fact that your code cannot run in the main thread, because Cocoa needs to run there. So to update any existing projects you must remove your code from the main function and place it in an auxiliary function which is called by cvInitSystem.

I have not yet made any benchmarks, so there is a chance that using Cocoa and QTKit at either 32 or 64 bit is not imperative for improving performance of your code. The main purpose is to allow the usage of other libraries in conjunction with OpenCV which already work at 64bit and may depend on Cocoa.

It is extremely easy to write OpenCL kernels (although there is room for improvement) and here is the warping kernel I have written.

mmreader, which I depend on for reading avi movie files no longer works. Images seem to be garbled by some sort of offset and data conversion. I suspect this stems from some 32 to 64 bit conversion that Matlab is not aware of. Anyway, so now I can’t read movies files until they fix Matlab which god knows when it will be.

Update for those thinking of installing Snow Leopard: 2008a, 2009a, 2009b (32 and 64 bit) all work fine. Aside from some bugs that must exist like the one above in specific packages, the general Matlab environment is fully functional.

Day 1: This will be great. I’ll use the Python C API to call python from Matlab. I’ll save the Python state as a Matlab variable and I can always start up my Python session where I left off.

Day 2: Alright.. maybe not. But let’s just try calling Python from C, I just want to make it work, not have it running efficiently.

Day 3: Ok, clearly Python has a crappy API. Moving to the client/server socket communication approach. Phew.. must it be this hard?

% Images = set of 2D matrixes that we want to convert to a movie (values range from 0-255)
% Frames = Pseudo RGB version Frames
% Mov = Matlab structure that holds the movie
Width = 48; Height = 48;
NumberOfFrames = size(Images, 2);
Frames = zeros([Width, Height, 3, NumberOfFrames]);
for i=1:NumberOfFrames,
Frames(:,:,1,i) = Images{i};
Frames(:,:,2,i) = Images{i};
Frames(:,:,3,i) = Images{i};
end
Mov = immovie(Frames);
movie2avi(Mov, 'movie.avi');

First is error that happens in the system_info.py which reads something like:

File "/sw/lib/python2.6/site-packages/numpy/distutils/cpuinfo.py"
line 79, in __getattr__
raise AttributeError,name
AttributeError: _has_sse2

To fix this you must edit the file system_info.py lines 107-114 to becoming:

#if cpu._has_sse2() and (dcomp  'mingw32' or dcomp  'gcc'):
extra_args = ['-arch x86_64', '-O3', '-msse2', '-mfpmath=sse', '-malign-double']
#    if get_gcc_version() >= '4.2':
extra_args.append('-mtune=generic')
#    else:
#        extra_args.append('-march=pentium4')
#        extra_args.append('-mtune=pentium4')
#info['extra_compiler_args'].extend(extra_args)}}}

This fixes the above error and also fixes an assembly error that happens later when compiling Blas bindings. The error:

error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’

The error is fixed by specifying the architecture of the computer, in this case x86_64.

Note: These values were generated on different processors and no attempt was made to see which one was ultimately faster. The idea was to see how, independently, each environment performed under complex matrix operations. All values are in seconds and averaged over 100 iterations.

Addition

Multiplication

QR

As you can see, the Mac version is finally starting to get numbers closer to that of Linux and Windows. With a better GUI (Cocoa based) I will finally stop writing C++ code for good.

For the face tracking project I have been involved in I need something that could open a movie file and as quickly as possible return matrix of the current frame in RGB format. Since it took me two days to get the results I wanted I thought I would make it publicly available so other projects can benefit from it in the future. (I am sure I will be using it again!)

The code is documented and only depends on the FFMPEG library. There is some usage of the Eigen library, but that can be easily removed for it is only used at the last step of getting a frame (for creating the RGB matrix).

The code can be downloaded from here

For those involved in scientifically programming, this should indicate that any reasonable algorithm can not only be run on an iPhone, but it will only slow down by a factor of 4, great given the fact that the phone is many more times smaller than a PC.