uCAM-II in RAW mode

[jphughes]

Hello: I am working with the uCAM-II and am trying to use RAW mode (RAW is necessary for my project). I have been trying to recreate the example 3.7.3 and I have several questions.

I get the following

Request: <aa0d0000 0000>
Response: <>
Request: <aa0d0000 0000>
Response: <aa0e0d44 0000aa0d 00000000>
Request: <aa010006 0303>
Response: <>
Request: <aa050100 0000>
Response: <aa0e0545 0000>
Request: <aa040100 0000>
Response: <aa0e0446 0000>
Response: <aa0a0100 9600>
Response: <ff010100 ff000000 ff000100 fe000001 fe000200 ff000100 ff020100 ff010202 ff000000 ff000100 ff010100 ff000200 ff010200 ff000100 ff000100 ff000001 fe000200 fe000200 fe010100 fd000101 ff000100 fe000100 ff010101 ff020101 ff000000 fe000000 ff000000 fe000000 00000000 ff000000 ff010000 00010000 ff010000 ff000000 ff000000 fe00ff01 0000ff00 ff000000 00010000 00010000 ff000000...

This capture was a completely black frame, that is, the camera was wrapped in a black cloth and put back into the box.

1) It seems that the "Initial" command aa 01... is not generating an ack although it seems to be working. I wait seconds and there is no response. Is this normal? This is reliable and repeatable. This is not an important point, but one I would like to mention.

2) I want to understand the bit ordering of the raw data. It says mode 06 is 565 (RGB). I assume the bytes of the 16 bit value is little endian and we can describe the bits in LSB0 form, that is the bits go 7, 6, 5, 4, 3, 2, 1, 0. The 565 RGB can be describes as r4, r3, r2, r1, r0, g5, g4, g3, g2, g1, g0, b4, b3, b2, b1, b0. The first word is "FF01". This means that the value is really 01FF. If I break up this into RGB, (00000)(001111)(11111) I get red=0, green=15, blue=31. This is not at all near black.

When I point the camera at a white light with the lens off, I get much different data,

Response: <f158255c f1642569 f0572658 ef612567 ef612761 ef60265c ef662764 ef5c2765 ee68276a ed6d266a ee6c276f ed6e2665 ef662863 ee652777 ef792873 f0732978 ed672866 ed6c297b ee782a82 ed7c2a81 ef7c2c7b ee822b7e ef7a2b7c ef802d80 ee832d7c ed7c2d81 ec842f83 ec7f2e79 ec813088 ec7f3084 ec813180 ed873181 ed83337d ec6b326e ec833382 eb7f3282 eb853488 ec843384 eb8a3483 ec7b357b ed7f337d ec833494...

In this case the first word is f158 which would be 58f1 (01011)(000111)(10001) or red=11, green=7, blue=17.

With the initial image format set to 16-bit Colour (RAW, CrYCbY) with a value of 08h, a sample white is

Response: <f39b269d f39e2794 f299289e f2a02892 f2952a9f f2a229a0 f2a329a4 f2a42ba2 f2a22ba4 f2ab2caf f2a72da9 f2a62cad f2ad2eaa f2aa2eb2 f2b32eaf f2ad30a6 f2b231b7 f1b531b4 f2b632b3 f1b031b4 f3b933b0 f2b633b9 f2bd34bd f3b534bb f3bb33ba f2b133c0 f3c734c3 f2c732c1 f4b634b9...

I am very happy with the CrYCbY mode since it seems more raw to me. I will rename it CrY1CbY2. Anyway, the first pixel is f39b. I assume this is little endian with 4 bits each so that the real values would be Cr=9, Y1=11, Cb=15, Y2=3

I am confused. Any help, pointers, etc. would be appreciated.

[ESPsupport]

Have you tried using the uCam demo program to satisfy yourself that it works? This will also help you see and understand the circumstances under which an 'init' might not be responded to.

If you let the camera 'idle' for 15 seconds between commands it will go to sleep and require a sync to wake it up. Could this be why you are not getting a response to the 'init'?

What baud rate are you using?

You have described the RGB format correctly, but what you are dumping appears to be closer to iRGB 8888. Are you explicitly converting it, or is your code mucking around with it? (Some modern 'unicode' compilers can't quire handle 8 bit serial streams and go to great lengths to 'convert' it into something that makes no sense to us humans).

If I place a lens cover over my camera and take a pic 'only' around 70 of the 19200 pixels are not 'pure' black

[jphughes]

Hello. Thanks. I have more information and can answer your questions.

1) I have not tried using your software. I am not a windows person. The good news is that the device is responding to me. The trace from my previous post is direct from the camera.

2) The time between the sync frame being received and the init is less than one second.

I have since updated my code to send the init again if there is no reply. The second time that I send the init command, I get a reply. So, no, the device is not going to sleep. The device is not responding to the init that I sent, so I am now sending it again.

I believe that sending the init command until I got a response is making things better. The sequence is now

Sync
Request: <aa0d0000 0000>.. Response: <aa0e0d00 0000aa0d 00000000>
Initial
Request: <aa010006 0303>... Response: <> This is now I show no response. The dots are 20ms each.
Request: <aa010006 0303>. Response: <aa0e0101 0000> This is the second time it is sent, and I get a proper reply.
Snapshot
Request: <aa050100 0000>. Response: <aa0e0502 0000>
Picture
Request: <aa040100 0000>. Response: <aa0e0403 0000>
Get Data Snapshot
. Response: <aa0a0100 9600>
.................................................................................................... .................................................................................................... .................................................................................................... .................................................................................................... .................................................................................................... .................................................................................................... .................... Response: <00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000020 00000000 00000000 00000000 00000000 00000000 00000000 00000000... many more trimmed.

3) I am using 57600 baud. My sync command is getting the proper response.

4) What I was dumping was not converted by anything. I know what this software is doing and the same code that is dumping the requests and responses is also dumping the image. Since the request and response are correct, I expect the data to be correct. I have the RS232 in full raw mode.

5) What I am getting now by sending the init twice seems more close to what you are expecting. Just a few pixels not 0.

In conclusion, i have confirmed that the init not getting a reply was a problem. I need to send it multiple time.

My last question is, can you help me with the CrYCbY format?

[ESPsupport]

Hopefully this code snippet helps

    cr := ord(pdata[procpos]) ;
    cb := ord(pdata[procpos+2]) ;
    r := min(255, trunc(ord(pdata[procpos+1])                 + 1.402   * cr )) ;
    g := min(255, trunc(ord(pdata[procpos+1]) - 0.34414 * cb  - 0.71414 * cr )) ;
    b := min(255, trunc(ord(pdata[procpos+1]) + 1.772   * cb)) ;
    if r < 0
    then r := 0 ;
    if g < 0
    then g := 0 ;
    if b < 0
    then b := 0 ;

    image1.canvas.pixels[x, y] := (r and $FF) shl 16 + (g and $FF)  shl 8 + (b  and $FF)  ;
    inc(x) ;
    if x = width
    then begin ;
         inc(y) ;
         x := 0 ;
         end ;
    r := min(255, trunc(ord(pdata[procpos+3])                 + 1.402   * cr)) ;
    g := min(255, trunc(ord(pdata[procpos+3]) - 0.34414 * cb  - 0.71414 * cr)) ;
    b := min(255, trunc(ord(pdata[procpos+3]) + 1.772   * cb)) ;
    if r < 0
    then r := 0 ;
    if g < 0
    then g := 0 ;
    if b < 0
    then b := 0 ;
    image1.canvas.pixels[x, y] := (r and $FF) shl 16 + (g and $FF)  shl 8 + (b  and $FF)  ;
    inc(x) ;
    if x = width
    then begin ;
         inc(y) ;
         x := 0 ;
         end ;
    inc(procpos,4) ;

pdata is a byte array of received data from the camera

[jphughes]

Yes, this helps. For CrYCbY I get data like:

Response: <00000000 ff00ff00 ff00ff00 00000000 00000000 ff00ff00 ff00ff00 00000000 0000ff00... many more skipped.

Looks like the data is calculated with a bit of rounding and "ff" actually being -1. I have looked at the even bytes and, for 100% black frame, they range from -3 to +4. This makes sense for a calculated value. For a normal picture that is not 100% black, these numbers will be very good indeed. For the odd bytes, the values are from 0 to 3. Again, very good. The calculation of turning a CrYCbY into two 24 bit pixels is very interesting. The even and odd pixels just differ in intensity. I gutes that is the way of handling CrYcbY.

As I have mentioned before, I am keenly interested in the most raw format from the camera. Most native resolution, most basic processing. Can you tell me the native resolution of the CCD array and the mosaic layout? Might there be a diagnostic mode (undocumented) that can get out the raw information from the CCD itself? Can you tell me the vendor and model of the CCD array?

My application may be a bit obscure, but I believe this discussions are valuable to your readers.

Thanks, Jim

[ESPsupport]

I don't believe there is.

If you look 'carefully' you will see that RAW pictures are really decompressed jpegs.

This is because there is not enough internal memory to hold a frame, so, internally the frame is compressed as it is 'read'. When you request the picture as RAW, it is simply decompressed inside the camera.

[mansoor]

Hi I am a new arduino user. I am trying to interface ucam-ii with arduino due / mega but till date haven't got any luck. I tried all the avaliable codes along with the libraries provided but cannot interface the camera with aarduino. At the moment i am trying to capture a raw image using ucam-ii and transmit it serially to the serial monitor in hex form.
Kindly any one having such kind of code please provide me as it will be of great help.

thanks

[DuraiS]

Hello Everyone,

I have query regarding UCAM-II Camera. I am able to get the binary data for 16bit Resolution, RAW Mode, RGB565 format. Would like to know how to convert RGB565 to RGB888 colour format? If there is mathematical algorithm to convert the RGB888 colour format, Please let me know the same.

Thanks
Durai S

[pauleilio]

Hello Durai,

Welcome to the Forum,

I have answered this question in your technical support request.

I hope it helps

Best regards

Paul