Notices

Agreed, that could actually salvage a picture one would otherwise throw away, IF (and I stress) the saving is of the raw info. The HW camera could serve a compressed stream (which I assume it does), in which case the denoise would be almost identical. If it serves only 5% better, waiting 10 seconds is a bad trade-off. Only one in 200 pics would be saved by this, and it would be a bad shot anyway. Sequence shooting would help more.

I am unsure what you mean by 1-2 EV. Exposure values have little impact on pre/post compression, most advantages of EV are due to exposure BEFORE the shot is taken. Once the shot is too dark, stretched, shaken, whatever, there is nothing to gain by RAW. Information has been clipped (or lost if smudged) and I very much doubt N900 has a HDR sensor that has low-light info that gets clipped by JPEG 24 bit compression.

Your statement is only relevant on high-end DSLR sensors that do above eight bit. Normal consumer cameras don't get clipped. E.g., my Sony does 12 bit per pixel, saving in RAW allows me to pull that info by sliding the data over (brightness) or compressing the range (contrast). That info is lost when saved in JPEG. That's why it HAS RAW.

@rambo, "if 10sec save times were acceptable you could get pictures of similar quality as high-end "prosumer" cameras" is a statement that, first of all, refers to best-case scenarios, with good light. A CCD prosumer in low light would be laughing all the way to the bank.

Second of all, there is no replacement for glass. While it is conceivable that in good lighting one could compare an N900 shot to a compact camera (pocket-compact), there is no way it gets comparable shots to a large-glass prosumer, even if the build is electronic and can't change optics, making them non-DSLR (prosumer).

Most of the noise in the shot is inserted by the CMOS sensor that fires up randomly in low light (high noise) - in low light only post-processing saves SOME of the data, but it has to be done inside the camera, since it implies median correction of successive/continuous exposures.

This has little to nothing to do with RAW. It helps a little, but doesn't fix anything.

My bet is the original talk was about post-processing, such as median denoise, precise demosaicing and color balancing. These does not equate in EV-equivalents.

If you are programming sort of person, look at http://maemo.gitorious.org/maemo-mul...n/gst-camera.c example. In handle_element_message() it shows how to handle RAW data buffer coming from v4l2camsrc, and on_chkbtnRawMsg_toggled() shows how to trigger v4l2camsrc to produce that RAW buffer.

RAW data is 10-bit BAYER (two bytes per element) if I'm not mistaken.

What goes for low light conditions, ndi is right that it is tough task for sensors in mobile phones and no postprocessing can make a replacement to a good sensor with smaller noise in a low-light conditions.
However, for typical Finnish winter day light conditions (which are far worse than normal light conditions we are assuming usually in such discussions) it is still possible to get good results with N900.
The infrastructure is there, a limiting factor of not supplying the IPP element switched ON by default was processing time as I said. It is program-level decision and has nothing to do with sensor quality.

I would say that many people try to express their opinions in a monochrome style, meaning that opposite for "good" is always "bad" or "evil". Life is full of shades, though.

indeed.

There's a real advantage in doing that, and if the camera serves RAW from the sensor, the gain would be quite hefty, if slow. Not everyone is in a hurry to shoot a sunset.

Just don't expect any miracles. Also, you might have to rewrite the camera app, so you'll be missing loads of features, like tagging, geo-tagging, etc.

I managed to build, execute, and debug the example_camera.c application that you mention, using ESBox, on my N900.

When I check the raw message checkbox, some sort of environment variable is set to CAMSRC_PUBLISH_RAW=True somehow. However when I take a snapshot afterwards, the execution flow in handle_element_message keeps going through the .rgb save path, and never goes through .raw path.

All the shots I could take with the raw checkbox checked are thus in .rgb format. I made a short python script to open, read, and dump the data into a PIL image: it is indeed an RGB 888 format, already demosaiced/debayerized.

So it seems I am not able to get any RAW really raw data. What am I missing ? The application GUI is a little messy and one or two elements seem to be a little going out of the screen, is there any other GUI element I should see that would trigger raw format ?

Thanks.

http://repository.maemo.org/pool/mae...7-2+0m5.tar.gz contains implementation of v4l2camsrc element. You can verify that it is indeed acting properly to non-NULL value of CAMSRC_PUBLISH_RAW environmental variable.

Regarding to the example program, I'm not sure whether it is update itself, I was referring to it purely to show an idea how to trigger the RAW buffer delivery from the v4l2cam.

Resuscitating the thread:

Can we take raw pictures with gstreamer?

For those who came to this thread when googling "N900 raw" or some similar way - Nokia N900 CAN shoot raw, the program is called "FCamera" (http://fcam.garage.maemo.org/fcamera.html)

This is what I'm looking for ... Emm ... I believed People up there had have lost in translating the first thread! Thanks!

BlessN900 has also the option to take photos in raw mode.
File is saved as .dng in DCIM folder