Notices

Wut? sounds like some kind of marketing BS. rawcam images are - as name suggest - raw's from sensor, so pictures are exactly like most RAW thing we get from sensor. Even if lens would be optimized for 16:9 ratio - which would be *very* strange - it would affect dump from sensor.

So, if You want 16:9 picture, just cut top and bottom part of picture from rawcam - You will have biggest 16:9 picture You're able to take with this camera (not possible to increase FOV in left and right)

It's due to lens characteristic - same issue was bugging generacies of N900 fcam/camera-ui2 users. Fortunately, some time ago, perfect (practically) solution was found - FOSS program CornerFix. Google for it - it works great, and is available for windoze, mac, and something else. AFAIK, sadly, no linux port, yet Would be great to have it on N900, as with Easy Debian's ufRAW, it would make it totally independent of another machines, for processing RAW photography.

/Estel

Hey Estel,
N9's lens is different than most mobiles lenses.
It doesn't just cut top and bottom out of the 4:3. It uses maximum width length from the sensor (with bigger FOV on the sides).
Take a look at this image and you will understand :


Otherwise I could just crop the image in photoshop, but that's not the case.

Well, thanks a lot for providing picture and explaining, but it's only confirming what I've said. (not completely - more about it to follow)

First of all, it's not about lens. This picture shows area of sensor, used in both cases. Lens, as You see from picture, produces circular view area, anyway - like all "regular" lenses.

Second, I get what You mean - but unfortunately, it's not good news, either In fact, it means that N9 sensor never takes advantage of it's full potential (8.7 Mpx), as "rows" are outside of optical area. So, 4:3 images are 8 Mpx, but 16:9 images are 7.1 Mpx, due to... Top and bottom being cut out (despite, that it's present in optical area)

Of course, as said, i understand Your point - in addition to cutting out top & bottom, it also widens 16:9 images a little - not enough to compensate for lost top & bottom (so 7,1 Mpx, not 8 Mpx), but still. No idea, if it's possible to force certain mode in program such as rawcam - qwazix, any comments?
---

BTW, to make things clear - this "special property" of N9's sensor isn't, in any case, advantage. It's a flaw - due to area produced by lens, sensor is never used to full potential. Using "special" mode for 16:9, is just "damage control", i.e. making this flaw less painful. No idea, why they have decided upon such design, but inability to use full sensor area in *any* mode, isn't advantage, no matter what.

anyway, it seems that everything, when advertised properly, can be perceived as thing of bonus value

/Estel

Cornerfix uses "Adobe DNG SDK 1.3", which is not FOSS and doesn't exist for (any kind of) Linux. Mentioned also in: http://talk.maemo.org/showpost.php?p...&postcount=752 But there are source code available under "Adobe License".

Very nice!

I took a quick test photo in very low light conditions with 1 s exposure and ISO100 (to avoid noise) and results are suprisingly good.


Wishes:
1, I would like to have longer exposures available if it's possible..

2. Magnify toggle (preferably fullscreen) would make manual focusing so much easier.

I also noticed something about the bug with stock video app showing gray overlay. After I play a video with mplayer (from commandline, not as kmplayer backend) the stock video player will show colors correctly again.

HUGE POST WARNING

A lot of replies, thanks guys for your input.


@paoletto: Latest rawcam is now in rzr's repo. The magnifying lens feature is a very nice idea but without further reaserch it seems hard to do. The frames that fcam streams are just 854*480. I would need to stream bigger frames, downscale them in real time and crop a portion to display full size, all that assuming that the N9 has enough power to process such highres frames in 30+fps


@vetsin: No 1 (led blinker) and 2 (soft shutter) are already there, just commented out. #1 because it doesn't work on the N9 and #2 because I thought nobody would use a on-screen shutter when he's got a real one. Snapping with the keyboard is not a feature I'm interested in implementing though, sorry. As for #3, I only can say that I'm not working on new features until the competition is over.


@Aapo: The official name of the application is ρcam. Greek letter rho and cam, pronounced rawcam. As I was afraid that I might run into problems naming binaries with a unicode character in them, I chose rawcam as a binary and package name (also imagine having to do apt-get install ρcam without a greek keyboard layout installed). I know it is not great marketing to having to explain the pronunciation of a name next to the name but what the hell, I like that name, I hope you take some awesome photos with it, pronounce it however you like

Binary not optified: already fixed in harmattan branch, got to merge the branches and push update, but I'll do that after the competition ends. I know it can be considered a bugfix, but if you absolutely want it you can lend it half meg of your rootfs for another week.

Fcam-drivers not depended upon: I'd swear I did that but if you say so it might have slipped. Will do fix.

Settings works for me, needs qt-components-10 which I also remember adding but this might be another slip. (or my whole control file is messed with the harmattan one or an older version)

Note to self: create DCIM if not exists.

@aStrike: A short rawcam history. When I got the N950 I was curious if I could take 12MP photos with it. I'd seen that fcam was available for harmattan so I tried to run the example apps on it. When I failed, I thought of giving a shot to porting fcamera. Fcamera builds fine, but it segfaulted due to some weird qtwidget bug. I tried a little bit to debug it, but then I thought that Fcamera's interface wasn't worth debugging, and that I could do a quicker, more familiar interface, based on the common point&shoot interface and SLR control naming practice. The N900 already had it's Fcamera so at first I didn't bother to port rawcam back. After implementing all the basic features I wanted, I started working on flash support. When flash support was completed, rawcam had finally a feature that Fcamera didn't, along with a better (in my opinion) interface, so the're was now a reason to backport. That is why it's in the N9/50 section

@Estel: I can request the exact image size I want from fcam, as long as it's less than the maximum sensor size. I just used sensor.maxImageSize() and got done with that. I can try giving the specific dimensions of the internal camera 16:9 pictures for the N9 and see what's going to happen.

@PhilG13: Awesome photo. Estel replied better than me for the vignette. See above for 16:9.

@Iadoga: 1s is the maximum shutter time for the N9 and 2.5s for the N900

Some more technical info for the curious.
One of the features missing from fcamera is exposure compensation. Total exposure in fcam is calculated as exp=gain*time where time is shutter open time in μs and gain is the logarithm with base 2 of the ISO number, plus one (gain = log(ISO/100)/log(2)+1). That means 1 => 100, 2=> 200, 3=>400, 4=>800 and so on. When pinning ISO in ISO priority mode, or time in shutter priority mode, rawcam (and fcamera for that matter) autoexposes the frame, receives the time and gain needed to expose correctly from the drivers, multiplies them getting a total exposure value, and then divides by the pinned value to determine the dynamic value.

I thought, that if I autoexpose and then just crank up or down one of the two values a step or two would work fine. I tried just multiplying time with 2 raised to the exposure compensation value (+1 stop e.v. means double the value) with unpredictable results.
-- BREAK --
In fact this is not strictly correct as the autoexposure algorithm has a priority on which value it changes which according to documentation, goes like this
-- END BREAK --
The exposure compensation worked as expected only up to about half a stop, and then it went nuts pushing the camera either to absolute darkness or blinding light. After trying various things such as moving the compensation up the process, or implementing a custom modified autoexposure algorithm I found out it is impossible to compensate with mathematically correct EV stops. It is possible to compensate by modifying the algorithm to request more burnt pixels or more black pixels, but that would need deep understanding of the autoexposure algorithm which I don't have, and when using the forked autoexpose function inside rawcam instead of the fcam one, something weird happend and the image froze after a few seconds, so I gave up.

I fully understood though why it isn't possible to do an exact compensation after autoexposure, and the easiest way to demonstrate this is with an example with completely out-of-scale fabricated numbers.
First though some background info about how autoexpose works:
As the N9 does not have an external light meter, the algorithm uses the color of the pixels of each incoming frame to compute the required exposure. If it finds too much burnt pixels it adjust down, if it finds many black ones adjusts up (oversimplified). While having a picture far off the correct value (imagine a completely white picture) the algorithm has little info on what the real exposure should be as everything is off the chart. It is impossible to know how much off the chart it is. It only knows that it needs to adjust down (by much). When the incoming frames start to get darker the algorithm starts to get some info about how far from the desired exposure we are, and turns down the rate of adjustment. After a few frames the desired exposure and real exposure converge.
Now to the actual example: Let's say that we frame a picture that the AE algorithm says that an exposure of 40 is needed, and user selected +2 EV compensation. (scale up exposure numbers by 1000 if you want a closer approximation of actual values) This would mean that our desired exposure value would be 160 (40*2^2). So just after the exposure we set the desired value to 160, set gain and time accordingly and request the next frame. Large exposure deltas do not happen over one frame for various reasons, but let's assume that it does happen for our example. So this frame comes, and is exposed at 160, which is pretty far off from 40. Autoexpose returns that the desired exposure is not 40 anymore, but 50, as it can't estimate closer to the truth with the info contained in the 160 frame. (the smoothing algorithm that is being used to prevent flashing from lightbulbs etc, only makes things worse - with that enabled it the next frame will return with something even higher). So recapping, we just got a frame exposed at 160, autoexpose says we need 50 and our exposure compensation multiplies this by 4 resulting in a desired compensation of 200. 200 is even more far away, autoexpose requests 65 now, we multiply by four etc. etc, until the screen is all white.

I also tried pinning the desired exposure value for some frames until values converge, but there wasn't any way to know if the differences were due to exposure compensation compensating or the user moving the camera around.

So I never managed to do exposure compensation right. I could still fake a slider with some arbitrary numbers, use real EV values about 1/3 of the real to compensate for the above behavior and cap it @+/-2EV to prevent it from getting out of hand, but this wouldn't be SLR grade mathematically correct exposure compensation, so I decided to leave it out.

I have to go now otherwise I'll fall asleep on the keyboard.

Great app!

Could you make a HW mods like volume buttons as the camera button. And maybe stealth mode to take pictures and the screen is black. Thanks for the contribution however!

Ough, that hurts - if fact that we're using adobe's dng raw format wouldn't be enough pain...

I wonder, if program compiled from source under "Adobe License" could land in non-free part of our repos? Surely yes, so it's the question about how possible (technically) compiling it for N900 is.

/Estel

This app not worked on my N9 - first I have installed v0.08,the program icon shows in the Menu,but by pressing do nothing,same issue and after reboot.
After that I have uninstalled v0.08 and I have installed v0.06 - same issue here...
Any ideas

ivo try running the app from terminal (/usr/bin/rawcam) to see the errors...I've used every version so far and all work...