maemo.org - Talk - camera-ui2 (now a part of CSSU) (updated 09. May)

maemo.org - Talk (https://talk.maemo.org/index.php)

- Multimedia (https://talk.maemo.org/forumdisplay.php?f=32)

- - camera-ui2 (now a part of CSSU) (updated 09. May) (https://talk.maemo.org/showthread.php?t=70870)

Re: camera-ui2 testers needed (updated 13.03)

If I had any clue how to install this I'd totally help. I have a quick question though regarding the DNG output you alluded to. Is the output similar to FCam or more like stock N900 camera output? The reason I ask is that the FCam output is incredibly difficult to profile because of color shift around the edges of the image where the image shows vignetting. Somehow the N900 stock camera app doesn't display any vignetting or color shifting on the edges.

Re: camera-ui2 testers needed (updated 13.03)

Quote:

Originally Posted by geohsia (Post 967609)

just extract it, and put it on under /usr/bin

Re: camera-ui2 testers neede

Quote:

Originally Posted by nicolai (Post 964358)

Sadly there is a bug in a gstreamer-component. Even if the buffer has the full 2592x1968 pixel data (this is the
raw resolution of the camera chip), the gstreamer plugin
only copies at image capture resolution (2576x1960).
That means there are some missing lines at the bottom of the
raw-image.

That may not be a flaw. I work with camera chips at work regularly, and know a bit about them. It may be that the upper/lower lines are actually masked lines (sensors with a black coating over them). Why would you do that? There are lots of reasons, but one of them is to help gauge how much drift you're getting and "noise" on the sensor. If you look at them, are they actually black (0), or something close to it? If it's the later, they're probably masked lines.

It may also be that the chip is not in the right mode. To get those masked regions sometimes the sensor itself has to be put into the right mode to report them back (vs just using them internally for row noise balancing and such). The cam developers at Nokia may have just gone with the default setup and let the pre-packaged module handle the dirty stuff for them. In that case, the code for putting the module into full-frame mode may not even be in there, even if it were open-sourced.

Great work on this. I haven't installed it myself yet just because I like having at least one stable camera. Lots of the ones I have around seem to be in various states of hacked, and I'm not willing to give up the one reliable one right now. :)

Re: camera-ui2 testers needed (updated 13.03)

Quote:

Originally Posted by cloud596 (Post 967619)

just extract it, and put it on under /usr/bin

I did and got a segmentation fault

Re: camera-ui2 testers needed

Quote:

Originally Posted by handaxe (Post 967575)

The same occurs with the new binary.... and indeed it is the exif that is wrong, as gimp displays the file correctly but notes that it "should be" rotated.

I was sure I did this right, but you are right, when rotating the device
clockwise 90 degree the exif orientation tag was wrong.
And fixed!
And I added a new keyboard short cut b/B for switching between
back and front-camera (only in *video* mode).
See attachment in my first post.

Nicolai

Re: camera-ui2 testers needed (updated 14.03)

The z key changes the zoom but the zoom slider doesn't slide as it does using the zoom rocker. Likewise, sliding the slider doesn't change the zoom.

I like those key commands very much. Makes macro focus muuuch easier as macro autufocus can be finicky.

Perhaps focus could be f 1, g 5 or 10 & h 50?

kudos!

Re: camera-ui2 testers needed

Quote:

Originally Posted by nicolai (Post 966843)

I found the reason for this, but no solution so far.
The original camera applications tags the videos
with an "classification" tag. This id starts with
noki://0/ followed by a 90 digit hex key.
I don't know what this key is.
In /apps/camera is a "device-id" key I don't know
what this key is either. But it doesn't seemed to be related
to this one.
If anyone has an idea what this key could be, I can
tag the video files the same way the original camera app
does it.
You can see your own classification id when you
play a video file with gst-launch:
gst-launch-0.10 -t playbin2 uri=file:///home/user/MyDocs/DCIM/<NAME_OF_THE_VIDEOFILE>

regards
Nicolai

The /apps/camera/settings/basic-settings/device-id
is a 25 byte random number.
And the classification id is made as follows:
Concat the 25 bytes device-id with 25 random bytes, and then compute the
sha1 hash of this 50 bytes. This results in a 20 byte hash key.
The classifcation-id is
20 byte hashkey + the above mentioned 25 random bytes!

Re: camera-ui2 testers needed (updated 13.03)

Quote:

Originally Posted by geohsia (Post 967758)

I did and got a segmentation fault

Are you sure you stopped the stock camera-ui before
trying to launch this one?

Nicolai

Re: camera-ui2 testers needed (updated 14.03)

i have tried using the dsmetool command way and just replacing camera-ui with your file both give me instant reboot, just replacing gives me the reboot loop.

am i going about this all wrong? am i best just leaving it for more experianced users?

Re: camera-ui2 testers needed (updated 14.03)

Regarding dsmetool: I have found that I get a reboot if I try it on the n900 x-terminal BUT if I ssh in (as root) I can get it to work. I once had problems via ssh but I got it to work after the reboot. Since then, I have been able to use dsmetool via ssh to unload and reload between camera-ui and camera-ui2 at will.

What happens if you "dsmetool -k /usr/bin/camera-ui" as root and then try to run camera-ui2 from the terminal as user? (Note need of path to executable - I forgot to mention that first off until I read Nicolai's response...)