Notices

Its 2584x1938 - 2576x1936 = 20656 pixels more, so 20656/4987136 = 0.00414 = 0.414% (approx.) more pixels if we used the full sensor capacity. Why should we care then?

Well it is 2592x1968 - 2576x1936 = 5101056 - 4987136 = 113920 so
113920 / 4987136 = 0.02284 = 2.3%(approx.)
But for me it's not a matter of why we care & why we don't care , I think it more simple : it is there so why don't we make it as an option ?!

@UJKU: but we can't capture more than the sensor can capture, can we?

Cost (of the coding) vs benefit (as seen in images).

Methinks Cost outweighs the other.

Yeah we cant but the sensor must be bigger than that nokia reports because if you take a picture with bless n900 you will see the resolution that i described

Yeah we can analyze it further and see who is bigger but since most of the coders here works for free , i just wanna it to throw this idea , if someone is interested in working on it ! this may be an interesting feature to add in the cameraui2 and is plus when comaring it to stock camera

I would rather have better pictures than more pixels. So if "someone" (it's always "someone", isn't it, never "me") wants to work on it, then they can spend their time better on things like removing the quality cap, as suggested earlier.

CCD sensor manufacturers cover their bums by specifying "effective" or "save" image dimensions that are on the order of about 5 pixels smaller on each side than the whole sensor. This is to allow for compensating various manufacturing faults that are most prominent at the edges. Some sensors allow using the full image size, others would not go over the effective size.

I personally think it's not woth it. 0.4% or 2%, you won't see the difference one way or another. Unless there are some bad pixels at the edge, then you will definiteky notice.

removing the quality cap is another feature that i want it too
I have used blessn900 and there are not bad pixels ,
It's like the overclocking thing
Just because most of the n900s arent stable ate 1 ghz this should not mean that we cant release an app that offer the possibility
Or the HD recording , normally my n900 would record at 20fps but this doesnt stop fmg from adding it as a feature

First of all, bugs need to be fixed. Then maybe some extra functionality.

Re bugs, and my attempt to collect the and report *proper* way to CSSU bugteam:

I tried it on two devices, one my "usual" everyday one, (thumb), and one freshly flashed (inc. emmc vanilla, which shouldn't be relevant). The 2nd device used cssu-thumb, later I reflashed it to stock again and used cssu-testing, then repeated tests.

On all three devices, I got positive results (aka bugs present) with ALL things reported, at some point, in this thread - including, but not limited to:

*autofocus suddenly becoming slow

* autofocus getting stuck at focusing only up to some random value (for example, few-centimeters - no matter what scene we point it at. When it get's stuck, it clearly *changes* focus, but always device to end up at the same value. Interestingly, value changes between "stuck" accidents, but during same "accident", remains the same.

*camera-ui getting frozen during saving of video, resulting in broken .mp4 container.

*camera-ui crashing randomly

*camera-ui suddenly starting to fail saving most of pictures took

*camera-ui suddenly showing black viewfinder (with all UI elements as they should be, though) and seeming like it "lost contact" with camera hardware (pressing autofocus doesn't move lens, etc) - until restart

*just as above, but with addition of camera-ui window getting clones, and showing proper viewfinder in that clone

...etc. The problem is, that ALL of those issues are not clearly reproducible - they just happen, quite often (especially during longer photo or recording runs - think few hours), if anyone cares to search for them. (I haven't found similar problems in stock camera-ui, when trying to replicate them there).

Now, I wasn't able to find ANY way of getting meaningful logs/debug content from camera-ui. No one who I asked about - including this thread, camera-ui2 thread, and CSSU bugtracker (inside camera-ui reported bug) was able to point me how to get meaningful logs/debug info from camera-ui. I assume that it doesn't have ANY, accessible to average Joe.

This result in complete inability to post a meaningful bug report, that would be anything more than things commented as rants.

Due to this, I'm "officially" giving up on attempts to gather those bugs and report them to bugtracker - at least until some sane way of getting debug output is introduced into camera-ui. If someone more knowledgeable is willing to pick it up, be my guest - it's not a full "rage quit", it's just fact that spending a total of ~90 hours of chasing those bugs, experiencing them, but being unable to report them in a way meaningful to maintainers is too frustrating.

Maybe things like attaching gdb or whatsnot would help, but I have no clue about such things ATM (to the point that I don't even know if it's relevant to this case), and I already spent too much time on this, getting only "worksforme and my girlfriend" answers - despite that reports about camera-ui2 being substandard are numerous (and the links just show a small bite of them).

For now, I'm using a simple hack to have camera-ui (vanilla) for everyday functionality, and run camera-ui2 manually, when I need higher quality video recording (and it's not so important, so I don't fear that it might get corrupted at saving), or some nice functionalities that camera-ui2 offers, like manual focus.

/Estel