SENDING YUV-TO-JPEG CONVERTED BUFFER AS A BITMAP from JNI to Android code...plzzz help...Not a Noob , Am i??

584 views
Skip to first unread message

s.rawat

unread,
Dec 17, 2011, 1:59:45 PM12/17/11
to android-d...@googlegroups.com, andro...@googlegroups.com, android...@googlegroups.com
HI,
I have been trying hard from past four nights to get this thing work but so far not able to do that.I have taken and modified few of the code from the ndk-sample(in the samples directory in the ndk r7) for plasma -sample for passing and mapping the bitmap from the JNI.
Following is my code snippet :


Android :

#this code is running in a thread

       Bitmap   mBitmap = Bitmap.createBitmap(320,240, Bitmap.Config.RGB_565);
       renderPlasma(mBitmap);

#this code is running in a thread

Native :

Java_<my_package_name>_DrawCanvas_renderPlasma(JNIEnv * env, jobject  obj, jobject bitmap)
{
    AndroidBitmapInfo  info;
    unsigned char**    pixels;
    int                ret =10;


    if ((ret = AndroidBitmap_getInfo(env, bitmap, &info)) < 0) {

        return;
    }

    if (info.format != ANDROID_BITMAP_FORMAT_RGB_565) {

        return;
    }

    if ((ret = AndroidBitmap_lockPixels(env, bitmap, &pixels)) < 0) {
        return;

    }


    /* Now fill the values with a nice little plasma */
    fill_plasma(&info, pixels );

    AndroidBitmap_unlockPixels(env, bitmap);//i am hoping that the bitmap has been mapped to the contents of "pixel" at this point.

}

struct vdIn *pvideoBuff = 0;//v4l2 structure which contains the raw YUV data
void fill_plasma( AndroidBitmapInfo*  info, unsigned char*  pxl )
{
    unsigned char* buf = (unsigned char* )malloc(pvideoBuff->framesizeIn);
    uvc_startCapture(pvideoBuff);//v4l2 function which returns the raw yuc data form the uvc compliant webcamera
    compress_yuyv_to_jpeg(pvideoBuff, buf, pvideoBuff->framesizeIn, 80, pvideoBuff->formatIn); //method to convert raw data into jpeg format- Quiet popular code on the web
    pxl = &buf;//i am thinking the pxl will have now all the contents of the jpeg converted buffer

}

//the bitmap being returned from the native code has to be drawn on the bitmap continuously.
canvas.drawBitmap(mBitmap, 0,0, null);

I suspect that pixel being a 2D array , I have to assisgn each array elements from the buf.Plz correct me or slap a rockstar reply to this problem.
Best Rgds and Thanks in advance
Softy


"..pain is temporary.....quitting lasts forever......"

360.gif

Stephen Williams

unread,
Dec 17, 2011, 4:37:42 PM12/17/11
to andro...@googlegroups.com, s.rawat, android-d...@googlegroups.com, android...@googlegroups.com
This line gives you a pointer to the pixel buffer in the Bitmap:

    if ((ret = AndroidBitmap_lockPixels(env, bitmap, &pixels)) < 0) {

Then you pass it into your drawing method:
    fill_plasma(&info, pixels );


void fill_plasma( AndroidBitmapInfo*  info, unsigned char*  pxl )

Then you allocate, at the C level, a completely different buffer:

    unsigned char* buf = (unsigned char* )malloc(pvideoBuff->framesizeIn);

Then you compress your capture buffer into jpeg data (a compressed image format, not a bitmap buffer) into that temporary buffer:

    compress_yuyv_to_jpeg(pvideoBuff, buf, pvideoBuff->framesizeIn, 80, pvideoBuff->formatIn); //method to convert raw data into jpeg format- Quiet popular code on the

Then you overwrite the temporary parameter variable pxl with the address of the resulting buffer.

You never got around to changing the bytes in the Bitmap buffer that you locked and unlocked.  And even if you had, you were working with Jpeg compressed data that would have been garbage as a Bitmap.  Bitmaps are simple arrays of bytes representing uncompressed pixels.  Additionally, malloc() allocated data is not something you pass back to Java to manage.  You should copy into Java-allocated buffers.

If the capture buffer is the same size as the bitmap, you simply need to map each pixel using yuv->RGB formulas.  If they are different sizes, you need to resize the image too.  There are fast built-in methods to do this well, but basically you create a pixel from a weighted average in color space of the pixels that the resulting pixel overlaps.

sdw
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

s.rawat

unread,
Dec 19, 2011, 12:27:02 AM12/19/11
to Stephen Williams, andro...@googlegroups.com, android-d...@googlegroups.com, android...@googlegroups.com
Hi Stephen, thanks for the reply,
Can you Plz elaborate the "methods" and "this" in your last sentence --> "There are fast built-in methods to do this well, but basically you create a pixel from a weighted average in color space of the pixels that the resulting pixel overlaps"
a ltmgfy link will be great !!!
Rgds,
Saurabh

"..pain is temporary.....quitting lasts forever......"



Stephen Williams

unread,
Dec 19, 2011, 2:39:45 AM12/19/11
to s.rawat, andro...@googlegroups.com, android-d...@googlegroups.com, android...@googlegroups.com
http://developer.android.com/reference/android/graphics/Bitmap.html#createScaledBitmap%28android.graphics.Bitmap,%20int,%20int,%20boolean%29

Many things in Java, especially graphics operations, are implemented
mainly by native code. I've traced 2D graphics calls all the way down
to very specific JNI calls for particular transformations or bitblit or
whatever. So, there's often little point in writing your own native
code to implement something that the libraries already do since often
they are well optimized. If you want to do something not already
included, then it can make sense to go native.

sdw

On Sun Dec 18 21:27:02 2011, s.rawat wrote:
> Hi Stephen, thanks for the reply,

> Can you Plz elaborate the "methods" and "this" in your last sentence --> "There are *fast built-in methods* to do *this* well,

Streets Of Boston

unread,
Dec 19, 2011, 9:49:21 AM12/19/11
to android-d...@googlegroups.com, andro...@googlegroups.com, android...@googlegroups.com
Problems in 'fill_plasma':
  1. The raw data of the pxl-array can not contain JPEG encoded data. Instead it must be encoded as RGB_565, each 2 bytes having 5 bits of red, 6 bits of green and 5 bits of blue.
  2. You can not assign the bitmap's raw-data array address (pxl) to your compressed buffer-address. Instead, you'll have to copy each individual pixel from 'buf' into 'pxl'. Use a for-loop and copy each byte from the buf-array into pxl-array.
Message has been deleted

Stephen Williams

unread,
Dec 19, 2011, 12:29:56 PM12/19/11
to andro...@googlegroups.com, android-d...@googlegroups.com, android...@googlegroups.com, Streets Of Boston
On Mon Dec 19 06:50:53 2011, Streets Of Boston wrote:
> See my answer in 'android-developers' group.
> Please, don't cross-post.
>

A) I'd already answered essentially the same thing, but doesn't hurt to
say it again in a different way.
B) You mean the message that you cross-posted?

Date: Mon, 19 Dec 2011 06:49:21 -0800 (PST)
From: Streets Of Boston <flying...@gmail.com>
Reply-To: andro...@googlegroups.com
To: android-d...@googlegroups.com
Cc: andro...@googlegroups.com, android...@googlegroups.com
Message-ID:
<23786539.1588.1324306161440.JavaMail.geo-discussion-forums@vbxw7>
In-Reply-To:
<CALwa49tNdJaeu0-ef4PvfMSdwfHX6gkoud8DLj4r7A+WNVw9=w...@mail.gmail.com>
References:
<CALwa49tNdJaeu0-ef4PvfMSdwfHX6gkoud8DLj4r7A+WNVw9=w...@mail.gmail.com>
Subject: Re: SENDING YUV-TO-JPEG CONVERTED BUFFER AS A BITMAP from JNI
to
Android code...plzzz help...Not a Noob , Am i??

Problems in 'fill_plasma':

1. The raw data of the *pxl*-array can not contain JPEG encoded

data.
Instead it must be encoded as RGB_565, each 2 bytes having 5 bits of
red, 6
bits of green and 5 bits of blue.

2. You can not assign the bitmap's raw-data array address (*pxl*) to

your compressed buffer-address. Instead, you'll have to copy each

individual pixel from '*buf*' into '*pxl*'. Use a for-loop and copy
each
byte from the *buf*-array into *pxl*-array.

;-)

sdw

Reply all
Reply to author
Forward
0 new messages