0.03 is here, and changes for upcoming releases

hi all,

linux is now finally an official part of OF - and the codebase is the same on all platforms.

please let us know if you have issues with 0.03. we are hard at work for 0.04, and fixing addon issues. We have some outstanding issues for linux, especially adding the video grabbing library that arturo posted, and helping solve some issues with packaging.

please check out:

wiki (dot) openframeworks (dot) cc
(we will start posting the URL fully once we have good captcha software in place)

specially: code -> linux for a list of linux questions we are thinking about.

any feedback about 0.03, or ideas about 0.04 are extremely appreciated!!


hi zach

congratulations for the new version.

We have some outstanding issues for linux, especially adding the video grabbing library that arturo posted

If I can help you there? is something related with compilation? I’ve also noticed that the structure of the video grabber has changed a little from the version you send me. If you haven’t changed the code i can send you an adapted version for monday or so.

thanks arturo -

we actually had a very simple question, can we swap out V4L with unicap ?
I saw that you had included both, but I think for us it’s getting a bit too huge to have 4 different grabbing codes wrapped into one file. If it’s ok to swap them, then let’s do it. we’ve actually already done 0.04, but for 0.05 we can swap it in.

also, we were wondering if it’s possible to build the video linux grabbing system so that it will pick the nearest frame size - ie, if you request 360x240, it will choose 320x240 without failing. this will help with folks that have dv cams for example, that only give full res, etc. We’ve added scaling code for windows (dshow) you can see - so that if videoInput grabs a different size, we scale it. Quicktime does this automatically via gworlds (although recently stefan mentioned an issue on 10.5 w/ this that we are investigating). There is some performance hit if you get an unsupported size (ie, if you ask for 320x240 and get back 640x480 which is scaled to 320x240) but that is outweighed by the ease of having code that runs on alot of different machine / camera setups.


About swapping in my opinion, it could be done without problem, I’ve mantained the two libraries with the define in ofConstants, just in case, but i was looking at the v4l module of unicap, and the code is really similar to the v4lutils module in of. I suppose that if you’ve already decided to have both on 0.04 the best solution is waiting to see if it has any problem.

About changing resolution, it’s already done. Not to the nearest, but to the camera’s default one. I’ll look at the directshow code, to see if it can be changed to guess the nearest resolution.

If you want to check out the direct show nearest resolution code - you’ll need to look at the videoInput.cpp file - which you can grab here:


It might be a little bit gnarly looking but you’ll find it in videoInput::start();

: )

and the resizing for win32 happens here:

in (void ofVideoGrabber::grabFrame()) :

// if (bDoWeNeedToResize == true){  

thanks arturo - if you make the swap we will add that to the next release.

take care!!