yashsingh1/xdaforums huggingface dataset:
[Defy General] Inlined:
I looked into libcamera.so and compared it to Milestone. I found that the file has some interesting camera properties, those are text values at offset ~85%.

One is "preview-size-values". It is set on Defy to 176x144,320x240,352x288,480x272,480x360,640x480. It seems to be limited to 640x480 max, I don't have explanation why. Milestone has different values, some are larger.

This value is important for video recording, as camera uses preview overlay as the source for OMX encoding (I got it by analysing logcat output). So basically, what you see with camera app preview is then captured, compressed and written to file during video recording. Also notice that if you select widescreen shots, preview area increases to almost whole screen, however due to actualy preview window is only 640x480, the image is stretched, and is not so sharp as with ordinary preview.

I compiled and tested native Android Camera app with different video sizes. I tried to set the sizes explicitly (to say, 1280x720, 720x480, etc) but got same error in logcat saying that requested size larger than allowed preview sizes. So we might want to modify libcamera.so at first.

Another interesting property is mot-video-size-values. It is used by built-in Motorola' Camera app, which technically supports 720p, but allows only those values specified by this property (also set to 640x480 at max for Defy).

I also looked into the Linux kernel provided by Motorola and found that camera is compatible with Video4Linux (V4L2). Camera device is /dev/video3. It can be opened from the shell using compiled C sources. I tried some V4L2 examples, they worked and provided some information about camera device, but failed to capture any data. There is another camera device called /dev/camera0, which seems to control power state of camera. All drivers are open sourced, but libcamera.so is not.

Most likely 720p support can be enabled, I believe it is just limited by software.
[Defy General] switchgott:
Realy realy good!!

We are going on :-)

Coudl you mod the file?

Can we take it from other phone?

But if it a software problem, then other software could do it?

I guess its a driver, lib problem.

Moto killed the function!!

But if its real, its a OMAP 3640 :)
[Defy General] Pq2son2:
Maybe I say a stupid idea :confused:. But anyone try to seek the component ID of the camera? we can use lspci. Maybe in this way we can understand the components of our movile phone.
[Defy General] switchgott:
Good idea, please could someone try it!Haven´t got my defy yet!
[Defy General] BizzaBoy:
The camera module is a MT9P012 from www.aptina.com. Attached the docs I could find, in case somebody wants to take a peek (plus, here the full specs http://www.trulydisplays.com/ccm/specs/5.0M Sensor Aptina MT9P012 Spec.pdf)

Looking at the kernel it does support the following mode (via pixel binning):

enum mt9p012_frame_type {

MT9P012_FRAME_5MP_10FPS = 0,

MT9P012_FRAME_1296_30FPS,

MT9P012_FRAME_648_30FPS,

MT9P012_FRAME_216_30FPS,

};

I suppose that the 1296 mode is usable for say 1280x960 (4:3, as the sensor is that format), or a cropped 1280x720.

N.b. that somebody could hack a 648_60FPS and a 648_120FPS mode, but that would require changing the kernel.

Also one should take a peek at http://www.omappedia.org/wiki/Camera-ISP_Driver which explains the other part of the infrastructure somewhat better. The cited libcamera.so really is the link between the ISP and the camera module.

IMHO the simplest way to get some decent camera performance is to nuke (or suspend) the camera serive and take over V4L2 directly via a NDK application. Simpler than to hack around in somebody elses binary. Then only libOMX_core.so needs to be patched, so that OMX can do the proper encoding.

The real nice thing with that approach would be that one could have direct MP4 output (rather than the 3gp output), and for stills, one could have a DNG file directly (which one can then open up in Lightroom/Photoshop).
[Defy General] switchgott:
Can you this???

Iam not a coder!

This looks realy good, that moto has only disable this function!

I dont know why!

Can you get it work?
[Defy General] Pq2son2:
BizzaBoy,

maybe we can contact with a Motorola Droid X or Droid 2 user and ask about the camera componentat that they have, I google it and I don't found anything about that.

Maybe we must look for other Android device that use the same camera component.
[Defy General] demolition23:
Acer Liquid use the same camera (MT9P012).

http://android.modaco.com/category/418/acer-liquid-liquid-modaco-com/
[Defy General] Pq2son2:
That is great and bad at the same time! XD

The good side is that we can try to join the two comunities to resolve the problem, or try it. XD

The bad side is that after one year any of their developers didn't found a solution. The blame? the framerate is not processed smooth enough with their hardware/software. (Maybe, and with luck, our hardware is newer than theirs :rolleyes:).

But if we dont try it we will not know...
[Defy General] reasly:
Hi

I am very interested in your attempt of device read. Can you provide more details about the V4L2 read result ?

e.g.

What is the result of the resolution query of the device ?

How you read the device (the device cannot read or write directly) and at which step did you fail , the error code ?

I would like to do a device read with native C later. I want to make sure the resolution restriction is in kernel driver layer or the framework.
[Defy General] Inlined:
I'm playing with sources provided here: h_t_tp://v4l2spec.bytesex.org/spec/a16706.htm

Take care of following changes:

1) Device is /dev/video3

2) fmt.fmt.pix.field should be V4L2_FIELD_TOP as in libcamera.so

3) IO_METHOD_USERPTR is used by libcamera.so

4) getpagesize() returns 0 for me (strange), so I set it to 4K by default

Everything works fine until VIDIOC_DQBUF in read_frame() that returns EAGAIN if device was opened with O_NONBLOCK. If O_NONBLOCK is commented, VIDIOC_DQBUF does not return at all. Seems like sensor is not streaming, I am looking into this in spare time.

So far, I see that possible resolutions allowed for V4L2 are strictly defined by /drivers/media/video/motcam.c. More interestingly, largest resolution is 2048x1500 (3MP). libcamera.so takes pictures using resolution 640x2000. I don't even know how data is then processed, but it might explain poor quality of resulting jpg file.

To get more information what is going on, make sure to enable debug logging of some kernel modules, i.e. by "echo 1 > /sys/module/videobuf_core/parameters/debug" and some other in similar way. Run dmesg and compare logs after your code and stock application.
[Defy General] reasly:
Thank you very much for your advice! Very helpful!

I tried to read the camera, the result is almost the same. The select function run timeout. If I read data after 2 second directly. The queue is already cleaned. The dmesg is like this (I set 6 buffers)

<6>[ 2730.491973] video4linux video3: w 640, h 480, fmt 31544150 -> w 640, h 480
<7>[ 2730.493011] vbuf: reqbufs: bufs=6, size=0x96000 [900 pages total]
<7>[ 2730.493316] vbuf: mmap setup: 6 buffers, 614400 bytes each
<7>[ 2730.494018] vbuf: qbuf: requesting next field
<7>[ 2730.501403] vbuf: qbuf: succeded
<7>[ 2730.501739] vbuf: qbuf: requesting next field
<7>[ 2730.508453] vbuf: qbuf: succeded
<7>[ 2730.508758] vbuf: qbuf: requesting next field
<7>[ 2730.515197] vbuf: qbuf: succeded
<7>[ 2730.515716] vbuf: qbuf: requesting next field
<7>[ 2730.522186] vbuf: qbuf: succeded
<7>[ 2730.522491] vbuf: qbuf: requesting next field
<7>[ 2730.529968] vbuf: qbuf: succeded
<7>[ 2730.530120] vbuf: qbuf: requesting next field
<7>[ 2730.532897] vbuf: qbuf: succeded
<6>[ 2730.533813] camise Sensor in detected mode
<7>[ 2732.536437] vbuf: dqbuf: next_buffer error: -11

I guess the reason is the camera is controlled by some hardware e.g. ISP and data is fetched directly by hardware with IRQ. So the file descriptor did not changed like the ordinary V4L2 device.

Maybe need feature research on how libcamera works?
[Defy General] Inlined:
Did you do anything special to get "camise Sensor in detected mode" printed? I've never seen this. Do you know what is your sensor? Mine is mt9p012. It is getting printed in dmesg while booting.

"ISE" (and camise) is most probably related to OV5xxx/OV8xxx sensors. Motorola complied kernel with support for both mt9* and ov5(8)* sensors.
[Defy General] reasly:
My dmesg during boot

<6>[ 0.000000] akm8973 -> I2C bus-2
<6>[ 0.000000] lis331dlh -> I2C bus-2
<6>[ 0.000000] kxtf9 -> I2C bus-2
<6>[ 0.000000] I2C-3 devices: HP_GEN_LENS,lm3554_led,mt9p012,camise
<6>[ 0.000000] HP_GEN_LENS -> I2C bus-3
<6>[ 0.000000] lm3554_led -> I2C bus-3
<6>[ 0.000000] mt9p012 -> I2C bus-3
<6>[ 0.000000] camise -> I2C bus-3

Here is the ordinary operation flow: (system camera)

open camera and start preview

<6>[ 6775.620574] video4linux video3: w 480, h 360, fmt 31544150 -> w 480, h 360
<7>[ 6775.620819] vbuf: reqbufs: bufs=8, size=0x55000 [680 pages total]
<7>[ 6775.620941] vbuf: mmap setup: 8 buffers, 348160 bytes each
<7>[ 6775.622283] vbuf: qbuf: requesting next field
<7>[ 6775.623901] vbuf: qbuf: succeded
<7>[ 6775.624389] vbuf: qbuf: requesting next field
<7>[ 6775.625671] vbuf: qbuf: succeded
<7>[ 6775.626129] vbuf: qbuf: requesting next field
<7>[ 6775.627685] vbuf: qbuf: succeded
<7>[ 6775.628265] vbuf: qbuf: requesting next field
<7>[ 6775.629425] vbuf: qbuf: succeded
<7>[ 6775.629882] vbuf: qbuf: requesting next field
<7>[ 6775.631164] vbuf: qbuf: succeded
<7>[ 6775.631622] vbuf: qbuf: requesting next field
<7>[ 6775.633392] vbuf: qbuf: succeded
<7>[ 6775.633972] vbuf: qbuf: requesting next field
<7>[ 6775.635162] vbuf: qbuf: succeded
<7>[ 6775.635711] vbuf: qbuf: requesting next field
<7>[ 6775.636993] vbuf: qbuf: succeded
<6>[ 6775.638092] camise Sensor in detected mode
<7>[ 6775.680236] vbuf: dqbuf: state is done
<7>[ 6775.680572] vbuf: qbuf: requesting next field
<7>[ 6775.680694] vbuf: qbuf: succeded

capture a frame (5M)

<6>[ 6772.477813] video4linux video3: w 640, h 2048, fmt 31544150 -> w 640, h 2048
<7>[ 6772.478393] vbuf: reqbufs: bufs=1, size=0x280000 [640 pages total]
<7>[ 6772.478698] vbuf: mmap setup: 1 buffers, 2621440 bytes each
<7>[ 6772.479553] vbuf: qbuf: requesting next field
<7>[ 6772.535919] vbuf: qbuf: succeded
<6>[ 6772.536285] camise Sensor in detected mode
<7>[ 6772.809020] vbuf: dqbuf: state is done
<6>[ 6772.820373] camise Sensor in detected mode
<7>[ 6773.132598] vbuf: qbuf: requesting next field
<7>[ 6773.132751] vbuf: qbuf: succeded
<7>[ 6773.134948] vbuf: dqbuf: state is done
<7>[ 6775.561187] turning off regulator
<6>[ 6775.619934] camise Sensor in detected mode
<6>[ 6775.620117] camise Sensor in detected mode
<6>[ 6775.620330] camise Sensor in detected mode
[Defy General] Inlined:
Hmm, I only see "I2C-3 devices: HP_GEN_LENS,lm3554_led" in my dmesg. Did you upgrade the phone? I did not. I don't see texts "camise" and "Sensor in detected mode" in kernel sources provided by Moto.

Anyway, in addition to /dev/video3, libcamera.so does something with /dev/i2c-3. Seems like to be related to "hp3a" or "isp" source directories in /drivers/media/video.
[Defy General] reasly:
Maybe because I am using a different ROM. I can using the original ME525 (Froyo). The libcamera.so is very small, only 5k. Open it there is only one function openHardware. It opens /dev/video3 , if succeeded, then goes to libsoccamera.so , otherwise liboemcamera.so.
[Defy General] BizzaBoy:
I don't think motocam is used. It's a mapphone, which uses the sensor directly.
[Defy General] BizzaBoy:
The HP_GEN_LENS thingy is simply a little lens that can be stepped to achieve auto-focus. In one direction it goes to infinity, in the other one towards macro.

The "hp3a" and "isp" directories are dealing with the processing part. Things like autofocus feedback, autoexposured and auto white balance are done (I think) via hp3a, which is a statistics collection module. "isp" does things like resicing, demosaicing, essentially the core camera functionality. On the other hand, OMX (and the underlying IVA) then deal with the JPEG compression.
[Defy General] Inlined:
So I continued looking into Defy's camera, and right now I am pretty sure that the sensor is Omnivision 5642. I know it may sound crazy, and different sensors were mentioned in this thread, some were listed in dmesg, however I believe Motorola has been fooling us by including these sensors in kernel. More interestingly they don't use them directly from libcamera.so via L4V's ioctls.

Instead, libcamera directly communicates with ov5642 by I2C. I wrote small program to detect ov5642 using device i2c-3 and slave address 0x3c. Reading from registers 300A/300B returns sensor id 5642.

libcamera.so controls the sensor based on data stored in file /system/etc/mot_ise_imager_cfg.bin. This file is library of I2C control registers to write and read. Header also says "OMNIVISION 5642".

I found one practical use of this information. We can reduce artefacts of JPG compression by changing ZZ in all occurances of "0x44,x07,0xZZ" in mot_ise_imager_cfg.bin to 0x01. (ZZ can be 0x04, 0x06 or 0x0c in USA stock sbf). This will increase size of resulting Jpg file 3 times up to 1,5 Mb (ordinary size is ~500Kb). Image will be a bit better, but don't expect huge improvements.

4407 is COMPRESSION CTRL07 register of ov5642. Bit[5:0], according to the datasheet, is quantization scale. 0x01 is the best option we can get.
[Defy General] thenext1:
I don't have my Defy yet, but I had an Acer Liquid (micron sensor) until a few weeks ago. I remember how the photos sucked because of the excessive processing (crazy edge sharpening) and limited dynamic range, i.e. areas of the image tend to be either blown out or very dark. Night imaging was also impossible.

Defy shoots are very different so they must be different sensors.

I have downloaded a dump of the linux partition of a rom, and I alsou found a reference to "OMNIVISION 5642" on a file header (i think it was the camera's firmware).

As to the compression value not changing blurriness, I suspect there's some processing done on sensor raw data directly by the IVA or in the camera's ISP that we have yet to discover.
[Defy General] |ErosizeD|:
well... if is an OMNIVISION 5642, it's better than other camera :p

Specs here:!!!

http://www.ovt.com/download_document.php?type=sensor&sensorid=65

720p at 60FPS GOOD!! and VGA at 60FPS :eek:

well if the processor have an IVA2+, we can record in HD ;)
[Defy General] BizzaBoy:
Very intresting. Are you suggesting that despite the code in maphone-camera.c the libcamera.so bypasses all of that and uses i2c-writes directly bypassing the kernel infrastructure ?
[Defy General] Inlined:
Yes, I saw what is included to mapphone-camera.c, but these don't seem to be used. libcamera.so does it's own business by i2c commands with only a few basic V4L commands. I'm in process of dumping i2c requests. So far, it is around of 1000+ registers just to setup preview, and another 500 to capture.

The fact that we can change jpeg compression by ov5642 register means that Jpeg compression is done on the sensor. It is powerful piece of hardware with 6K ram to store auto-focus firmware. Now we need study it.
[Defy General] BizzaBoy:
Yes, the JPEG on the module is intresting. You hacking the *.bin file to change the compression ratio kind of proves that it's a OV5642 and not a MT9P012 (which does not have compression). Still confusion that the kernel is prinitng out the driver loading for the latter sensor. On the other hand the registered I2C devices don't list the MT9P012. The OV5642 makes kind of sence if the original CPU for the DEFY was supposed to be a OMAP6310, without IVA. Then this on module JPEG compression is rather useful.

The autofocus is MOST LIKELY not done throu the OV5642, as the HPLENS module is registered on the I2C bus. Could be that the DEFY is using the HP3A and the ISP module on the OMAP3 to do AF/AWB/AE. Otherwise the ISP ioctls in libcamera.so would not make a lot of sense.
[Defy General] BizzaBoy:
Sorry, quick 2nd followup. The setup for the OV5642 is rather static, you write the control data once, and then wait for the image stream to appear.

On the other hand, if AF is done on the OMAP3 this has to be done in RAW or YUV, as JPEG decompression in the ISP is not supported. As soon as AF is locked, libcamera.so had to switch to JPEG compression and resetup everything. Seems to be awefully complicated. Why not simply use the OMX pipeline to compress to JPEG then, after a RAW/YUV image has been captured ? However that would contradict your observation with tuning a register on thre OV5642 chaning the JPEG file size.
[Defy General] Inlined:
I believe autofocus is done by ov5642 itself. Refer to section 2.1 of http://www.trulydisplays.com/ccm/specs/5M Sensor OV5642 Ap Note.pdf

There is a series of I2C commands in capture mode, when register 0x3027 (STA_FOCUS) is constantly read. At first, 0x01 are being returned (S_FOCUSING), then after 0x02 (S_FOCUSED) other commands start.
[Defy General] dau_:
So, what other devices are using the OV5642? Would be interesting to compare images to see if the Defy's camera quality is due to software or hardware issues.

Edited: Wait a second, are you sure it's the OV5642? Because that seems to be the backside illuminated sensor used in the iPhone4.
[Defy General] franek123:
Sensor used in Iphone4 is OV5650 or the OV5653 = 5MP, BSI, 1.75um pixel, RAW RGB.

Chipworks saying:

"The sensor in the iPhone is believed to be the OmniVision 1.7 as disclosed by Apple. We made an error in our post describing it as 1.4 and have fixed it.

We are expected to have the camera module in our RE labs today and will fully confirm the device. (It was torn down in California)."

Sensor used in Defy OV5642 = 5MP, BSI, 1.4um, RAW RGB, RGB, YUV (pixel size 1.4um like in 8MP sensor)

link: image-sensors-world.blogspot.c0m/2010/06/iphone-4-bsi-sensor-is-omnivisions.html (replace 0 zero in c0m = o)

Sample image from small form pluggable camera module (image sensor OV5642) with interchangeable lenses:

link: search in google e-CAM50_CU5642_MOD - Custom Lens Camera Module

(new users are not permitted to post outside links)
[Defy General] dau_:
Thanks. I somehow missed the Chipworks update. Makes much more sense this way.

Those sample images are not really looking any better than what i can get from my Defy. Oh well, so maybe the sensor is really just that bad.
[Defy General] Simplestas:
If your findings are true, libbayercamera.so, liboemcamera.so, libhpimgapi.so, cameracalfiledef5m.bin, cameracalfiledef8m.bin files are junk for different hardware?
[Defy General] BizzaBoy:
The Cal files are there for compensating for the IR filter, lens shading, gamma .... and other things. The "5M" vs. "8M" might just be for the 2 classes of sensors they put into the platforms.

I have to admit I am also at a loss about the difference between libbayercamera.so and liboemcamera.so (then there is also libsoccamera.so).

What I found out is that the DroidX/Droid2 line does not use the mot_ise_imager.bin file (did I get the name right ?). So files based off those ROMs might not work with the DEFY. The fact that Milestone 2 based 2.2 froyo ports to the DEFY have camera issues, kind of proves this point.

On the birght side, I edited build.prop/media_profiles.xml on a 3.4.2 based ROM and got 640x480 @ 30fps with with 8mbps going. That is intresting for 2 reaons. I believe that with 8mbps reasonable 720p coding should be doable (even if it's only 24fps). The other really, really intresting fact is that the 8mpbs matches the DroidX/Milestone2 for the h264 codec, whereby at least the last one does 720p.

Editing build.prop/media_profiles.xml does not get 720p alone. One also needs to tell liboemcamera.so (and maybe libbayercamera.so) that both preview and video sizes of 1280x720 are supported. Whenever I did some binary editing there, I had to reflash my phone afterwards.

What's really puzzeling to me is that the Milestone2 also uses a 5mp sensor. Why in the world would Motorola use a different setup for handling the camera to begin with ? IMHO the only hope is to wait for newer models to come out of Motorola that use the same base platform (like the CLIQ 2), but support 720p.
[Defy General] puked:
I unpacked the 720p_and_fullscreencam_update.zip, chaned the build.prop and media_profiles.xml like suggested on the last page in the thread in the development forum (not allowed to post there...), ziped it again and installed it via clockwork recovery (install zip from sd card) (pays rom). Did a wipe before.

Now the camcorder won`t load. 720p playback doesn`t work either.

What did I do wrong?!

Edit: works now...

-.-
[Defy General] -juanito-:
how i can change camera quaity ?

i put bin file in / system / etc / and restarting my defy but nothing new in camera

http://xdaforums.com/showthread.php?t=966800
[Defy General] insestito:
Thanks !!!

This is for photo camera only.
[Defy General] -juanito-:
ok but before i put bin file in defy i shoot a photo then put bin file in defy and shoot a photo and i look to pictures..photo 1 like photo 2 !!
[Defy General] ArtemDement:
OV5642

Yes, it is interesting, but which document contains a description of the output JPEG from sensor ? I have datasheet (CSP3) PRELIMINARY SPECIFICATION version 1.11 january 2009 and I cannot find description of procedure JPEG output from OV5642.
[HD2 Android Q&A, Help & Troubleshooting and Genera] Dakey:
Hi all

is it possible to make the M-DEEJAY CM7 1.6 ZIP version use a EXT3 partition on SD to store the apps that I will install.

I've already format my SD but in Storage menu under settings, it shows only the Nand space.

DO I have to install APP2SD+.apk ?

Or something else?

Thanks in advance.

Dakey
[HD2 Android Q&A, Help & Troubleshooting and Genera] hrockh:
http://xdaforums.com/showthread.php?t=905089

and use the latest version

1.8a as I'm writing
[HD2 Android Q&A, Help & Troubleshooting and Genera] matt-86:
HI!

until now i tried a lot of Android builds and still didn't find the one that suits for me. I really liked some features of certain roms that are from sd and nand.

I would like to ask if there is a kind developer that would like to develop this rom. I'll write the specifications including links and photos so everything can be more simple.

I am an Europe Hd2 user but maybe also users from TMobile would like to have this rom.

So, let's start...... :

1. Base on Desire HD (i think it's a good base)

2. Data.img on Sd or ext4 partition(maybe better ext4 partition)

3. ClockworkMod Recovery support so we can also update it and backup it

4. Rmnet , i still didn't understand the difference but i see that it's better for a lot of users

5. Everything working, no bugs like gps, etc...

6. No boot sound

7. Riptide power bar in notification bar ( it's the bar on the top: http://xdaforums.com/attachment.php?attachmentid=457097&d=1291592258) (This has been got from this rom that i had and it was a really good funcionality and i thank the developer of this rom: http://xdaforums.com/showthread.php?t=839410 )

8. Everything skinned ( i really liked the android of the riptide power bar ;) )

9. % Battery

10. Android 2.3 keyboard (Like the one in the rom of the link above (7. )

11. File/Root Explorer or App installer installed in rom (still i don't understand why android comes without one)

12. Maybe a call recorder...

13. Fast, smooth, stable, deodexed, rooted and maybe i'm missing something else

Ok should be everything at the moment, maybe some other idea will come in my mind, otherwise i'd like to hear other users for ideas and suggestions.

Thanks and i hope for a good developer to grant my wishes :p
[HD2 Android Q&A, Help & Troubleshooting and Genera] joshkoss:
Moved to General Forum and reopened :)
[Nexus One General] MinaSamy:
Hi all Where can I buy an unlocked google nexus one phone from Canada ?

thanks
[Nexus One General] guitar_east:
http://store.mobilicity.ca/product.asp?pf_id=37102M

Moblicity sells them. It won't work 3G on Bell/Telus/Rogers/Fido/Virgin. But it'll work on Wind and Moblicity. Honestly, try Craigslist or Kijiji