hopkinskong
Posts: 22
Joined: Sun Jul 03, 2016 9:35 am
Location: Hong Kong

image_encode BGR888 "B" and "R" swapped

Thu Jan 26, 2017 8:40 am

I am using img_encode to encode raw BGR888 frame to JPEG. The input and output port have reported the correct color format. However, I got Blue and Red color space swapped in the result jpeg image. I even tried with different width and height and there is no difference.

My BGR888 data have the following layout:

Code: Select all

<px0_b><px0_g><px0_r>...<pxN_b><pxN_g><pxN_r>
To really test Blue and Red color have switched, I have create a (supposedly) blue image by:

Code: Select all

uchar *fakeImg=(uchar*)malloc(800*600*3); // 800w*600h*3ch
for(int i=0; i<800*600*3; i++) {
if(i%3==0) { // at Blue channel
fakeImg[i]=0xFF;
}
}
The ouput JPEG image is Red in color.

Is this a bug in the firmware, or I need to fill in each byte in the reverse order (I am currently using memcpy to copy the data with the size calculated with slice height and call OMX_EmptyThisBuffer to empty the input buffer)?

Thanks.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17896
Joined: Sat Jul 30, 2011 7:41 pm

Re: image_encode BGR888 "B" and "R" swapped

Thu Jan 26, 2017 9:54 am

I think you have assumed big endian rather than little endian representation. I cannot see the firmware being wrong (although there was an issue some while back with a switched order, but that has been fixed - you are up to date with firmware?), but it is possible.

I'll take a look today if I get the chance.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

hopkinskong
Posts: 22
Joined: Sun Jul 03, 2016 9:35 am
Location: Hong Kong

Re: image_encode BGR888 "B" and "R" swapped

Thu Jan 26, 2017 11:23 am

jamesh wrote:I think you have assumed big endian rather than little endian representation. I cannot see the firmware being wrong (although there was an issue some while back with a switched order, but that has been fixed - you are up to date with firmware?), but it is possible.

I'll take a look today if I get the chance.
I am doing memory to memory copying, do endian is an issue? Because I still get the same issue when I decode a jpeg with opencv(which I think it should conform the endianness of the system), and encode it back with omx.

I just updated my firmware via rpi-update and rebooted. The problem is still exists, but the produced image seems brighter than the previous one...weird.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: image_encode BGR888 "B" and "R" swapped

Thu Jan 26, 2017 12:05 pm

The swap was on the camera component output ports only and resulted in it being opposite to all other components - viewtopic.php?f=43&t=148432

image_encode has to convert to YUV to encode JPEGs anyway. It may be a trivial task to add support for OMX_COLOR_Format24bitRGB888 too - I'll have a look.
Changing the component behaviour at this point is not going to happen - it has the potential for breaking far to many existing applications.

The definitions of BGR888 varies between different APIs, so don't necessarily expect OpenCV BGR888 to be the same as IL BGR888, or MMAL, or V4L2. You have to check they are specified the same.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

hopkinskong
Posts: 22
Joined: Sun Jul 03, 2016 9:35 am
Location: Hong Kong

Re: image_encode BGR888 "B" and "R" swapped

Thu Jan 26, 2017 5:36 pm

6by9 wrote:The swap was on the camera component output ports only and resulted in it being opposite to all other components - viewtopic.php?f=43&t=148432

image_encode has to convert to YUV to encode JPEGs anyway. It may be a trivial task to add support for OMX_COLOR_Format24bitRGB888 too - I'll have a look.
Changing the component behaviour at this point is not going to happen - it has the potential for breaking far to many existing applications.

The definitions of BGR888 varies between different APIs, so don't necessarily expect OpenCV BGR888 to be the same as IL BGR888, or MMAL, or V4L2. You have to check they are specified the same.
Thanks for the clarifications. So now when my input port is specified with BGR888, I actually need to supply RGB888 data?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: image_encode BGR888 "B" and "R" swapped

Sat Jan 28, 2017 9:51 am

The good news is that it appears all the relevant code is already in place to support OMX_COLOR_Format24bitRGB888 on image_encode, so it's solely a plumbing job and some testing.
I have the plumbing done in a manner I expect to work, but writing a test app is likely to take longer. I'll give it a whirl under MMAL as that should be quicker and easier but still uses the same GPU code on the expectation that it will follow through to IL correctly.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4447
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: image_encode BGR888 "B" and "R" swapped

Wed Feb 08, 2017 9:31 pm

The firmware update available via "sudo rpi-update" should support OMX_COLOR_Format24bitRGB888 correctly now.
Don't use rpi-update on a critical machine - it is the cutting edge branch and has the possibilities of regressions.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Return to “OpenMAX”

Who is online

Users browsing this forum: No registered users and 1 guest