When I was capturing images to process with a temporal median filter I used mplayer to capture a yuv stream. I am not sure if it delivers actual raw data or not, but it seemed nice to me. (i.e., I didn't test to make sure it wasn't JPEG-compressing the image and then delivering me decompressed yuv frames) You can also try to use gstreamer... And both can also save in lossless like png, without jpeg noise a priori.

http://talk.maemo.org/showthread.php?p=357615

***

I am quite excited about doing AR and other computer vision and (image processing in general) applications with NITs, but I became a little suspicious lately that we don't have the tools to take full advantage of the processor. How do I create an application using OpenCV, OpenMAX or any other libraries, making sure I am exploring DSP stuff? (I'm not sure N8x0 offers much, but N900 should have that NEON thing, right?)

For example, I am implementing this algorithm called MonoSLAM. One of the tasks I need to perform is to match features in sub-regions of images captured from the camera. I'm not sure if the processor would bear it, but my first try would be to match using normalized cross correlation, and for that I need to calculate DFTs of image patches, and calculating image integrals would be nice also. Are there libraries available to do this kind of low-level image processing to me? Can I even implement them by myself somehow? Can I use GCC, ou do I need some sort of proprietary compiler?

I remember some time ago people were talking about making an OGG decoding library that made use of the DSP resources. A Nokia developer, if I am not mistaken, said it probably wouldn't pay off. How come??

I want to see a "demo" of the OMAP DSP... I want to run two programs, one compiled with and other without the "magical library" that make signal-processing tasks faster. And if it's not much better, I want a different processor, without useless DSP things that we can't/don't need to explore. There are few things I hate more than a processor with unused instructions.

I am very concerned about all this because only the other day I discovered, after a long time working with OpenCV just for prototypes, that you need some proprietary Intel library to have a really neat OpenCV implementation. No SIMD for the "free" crowd. I think that's kinda lame... Now I'm trying to figure out how things are happening with OMAP. Is it the same? To make full use of SIMD I need some proprietary compiler or library? If that is the case, I'll end up going to program for my Chinese Z80 music player. At least I get the feeling I am using all the hardware available...

Sorry for the long rant, I am not sure I should start another thread since some many concerned people are around here anyway.

I am not hijacking the thread. I am just asking: what are the tools we should be using to make the best image processing applications possible for the NITs? How should i implement my feature matching algorithm? How should I implement my own demosaicing algorithm (supposing we can get the really-raw data from the camera)? I want to make an audio synthesizer too... How do I make it as efficient as possible?

I think you are mixing things together for no real benefit. NEON is part of ARM core, ARM is capable to run both NEON and ARM pipelines in parallel in some cases. DSP core is a separate part, has different assembly and generally speaking you can have devices where DSP is not present but NEON and VFP are supported, like BeagleBoard.

Look at NEON optimizations Siarhei Siamashka did for pixman: http://cgit.freedesktop.org/~siamash...rm-neon-update in his development tree. NEON code can be written by hands but with fairly recent gcc autovectorization on -O3 level could produce you NEON code on ARM. The latter is not always of good quality and generally needs more love from compiler folks to be useful. Siarhei's code makes good use of aggressive prefetching to allow both ARM and NEON be busy.

DSP programming in OMAP chipsets is a different story. You need a proprietory tools for it. But once you've done your algorithms and compiled them, you can use recently opened Maemo's gst-dsp to hook up algorithms into gstreamer pipelines. It works faster and more reliable than original TI's library for DSP communication. See http://maemo.gitorious.org/maemo-multimedia/gst-dsp for more details in the code.

There is also OpenMAX bridge for gstreamer: http://maemo.gitorious.org/maemo-multimedia/gst-openmax which has been in use for some time but also needs more love before becoming really useful. gst-dsp and NEON optimizations approaches worked better.

Thanks so much! I have only recently heard about NEON, and I am still understanding where it sits. I'll sure take a look at that pixman code.

The DSP in OMAP is only a TI thing, right? I need a proprietary compiler to use it? Are there at least open specifications of how it works, or do we need to reverse-engineer the thing to at least play with it a bit?

Yes, it is TI's product. Read http://focus.ti.com/lit/ug/spru732h/spru732h.pdf and related documents if you want to get understanding how to work with it. Tools are available on TI's website. http://software-dl.ti.com/dsps/dsps_...index_FDS.html for example.

In case someone is interested, a computational photography course using N900s has just started at Stanford

http://www-graphics.stanford.edu/courses/cs448a-10/

Hartti

Maybe you already know this, but here it is: http://qtpfsgui.sourceforge.net/
a open source program to create hdr images. Would it be possible to use it directly on the N900?
(note: I didn't test it yet)

I have been using enfuse in Easy Debian to create HDR images on my device. It does a decent job, takes about 6 minutes to produce a final picture. My main problem is that the script by davost in the HDR thread to take three "bracketed" photos doesn't focus correctly.

This was always an interesting thread, so I figured I'd might imform those tracking that F-Camera, was released for the n900, though it currently has some install issues. It is the results of the Frankencamera group at Nokia Research and Stanford.

Take close-up photos of a record and have it find the grooves, reconstruct the wave form and play the music. (a pocket record player!)