Does WB_SWAP bit of IMXRT1060 PXP module work correctory?

[takayuki_ishii]

Hello community,

I'm just running SDK drivers example of CSI named evkmimxrt1060_csi_ccir656.

In source code of source/csi_ccir656.c, I changed psBufferConfig.swapByte setting from false to true.

pxp_ps_buffer_config_t psBufferConfig = {
.pixelFormat = kPXP_PsPixelFormatUYVY1P422,
.swapByte = false,　ー＞ true,
.bufferAddrU = 0U,
.bufferAddrV = 0U,
.pitchBytes = DEMO_CAMERA_WIDTH * APP_BPP,
};

But, LCD output have no effect.

It can show correct picture both false and true setting.

I hope that if swapByte = true, each 16bit data will swapped from UY, VY to YU, YV.

Does WB_SWAP bit in PXP_PS_CTRLn register work correctry?

Best regards,

Ishii.

[victorjimenez]

Hello Ishii,

The WB_SWAP function swaps bytes within the 16-bit words of the PS buffer. I would recommend using this option only if your current pixel format requires it. It would affect how the pixels are managed while going in the PS buffer before the PXP processes like rotation or color conversion.

Regards,
Victor 

[takayuki_ishii]

Hello Victor,

Thank you for your reply.

Now we use uvc camera it can output only YUYV422 format.

So, we do YUYV422 to UYVY422 byte swap by CPU and CSC and scaling by PXP.

Output RGB color is correct and it can show LCD, but performance is bad.

We think that if WB_SWAP bit set from 0 to 1, it can do byte swap + CSC + scaling by PXP.

But both WB_SWAP=0 and WB_SWAP=1 settings are no effect.

So we test WB_SWAP bit with SDK parallel camera example.

The effect of WB_SWAP could not be confirmed.

Does WB_SWAP bit work properly?

Best regards,

Ishii.

[victorjimenez]

Hello Ishii,

I'm not sure that I understood correctly. Could you please clarify what is the result that you are expecting when setting the WB_SWAP to 1? 

Regards,
Victor 

[takayuki_ishii]

Hello Victor,

Thank you for your response.

I attached excel file to inform data format.

Please feel free to ask me any questions.

Best regards,

Ishii.

[victorjimenez]

Hello Ishii,

In the Excel file that you attached I saw the following tables: 

I think that the first table is wrong, it should look like this, correct? 

Also, your understanding of how the WB_SWAP bit works is correct. Before you mentioned, "The effect of WB_SWAP could not be confirmed.". What do you mean by this? What tests did you make to confirm this? 

Regards,
Victor 

[takayuki_ishii]

Hello Victor,

I modify SDK sample (evkbimxrt1050_elcdif_rgb) to show PXP output result.

YUYV422 capture data are saved from SDRAM to vga_yuyv.bin file and convert it to C array code.

And run PXP CSC YUV422 to xRGB888 and output it to LCD.

PXP output result are same value both WB_SWAP=0 and WB_SWAP=1 setting.

Result seems doing YUV -> RGB convert with YU and YV byte swapping.

So befor PXP, byte order change from YU to UY and YV to VY by CPU and run PXP,

Color space conversion to work correctly.

Attached files are result of this test..

• elcdif_rgb.c : modified sample source.
• elcdif_rgb.h : modified sample header
• lcd_buf00_WB_SWAP_0.bin : PXP output buf0. UYVY1P422 -> XRGB8888, WB_SWAP=0
• lcd_buf00_WB_SWAP_1.bin : PXP output buf0. UYVY1P422 -> XRGB8888, WB_SWAP=1
• lcd_buf01_WB_SWAP_0.bin : PXP output buf1. UYVY1P422 -> XRGB8888, WB_SWAP=0
• lcd_buf01_WB_SWAP_1.bin : PXP output buf1. UYVY1P422 -> XRGB8888, WB_SWAP=1
• MCUXpresso_PXP_UYVY_RGB_WB_SWAP_0.bmp : MCUXpresso capture data WB_SWAP=0
• MCUXpresso_PXP_UYVY_RGB_WB_SWAP_1.bmp : MCUXpresso capture data WB_SWAP=1
• vga.png : UVC camera picture we hope.
• vga_yuyv.bin : UVC camera save data. 640x480 x 2Byte
• vga_yuyv.bmp : Convert vga_yuyv.bin to .bmp by PC tool.
• vga_yuyv.c : Convert vga_yvyv.bin to C array source
• vga_yuyv.h : Header file for vga_yuyv.c.

Best regards,

Ishii

[victorjimenez]

Hello Ishii,

I'm checking this internally. I will give you an update as soon as possible. In the meanwhile, I wasn't able to understand the following lines of your last reply, could you please explain this a little bit? 

Result seems doing YUV -> RGB convert with YU and YV byte swapping.

So befor PXP, byte order change from YU to UY and YV to VY by CPU and run PXP,

Color space conversion to work correctly.

Regards,
Victor  

[takayuki_ishii]

Hello Victor,

Sorry my late reply.

My intention is as follows.

Result seems doing YUV -> RGB convert with YU and YV byte swapping.

As in section "36.4.9 CSC1 Operation"  in Reference Manual, YUV -> RGB conversion use a following formula.

R = C0(Y+Yoffset) + C1(V+UVoffset)
G = C0(Y+Yoffset) + C3(U+UVoffset) + C2(V+UVoffset)
B = C0(Y+Yoffset) + C4(U+UVoffset)

In YUV422/YCbCr422, Odd pixel and even pixel use following.

R0 = C0(Y0+Yoffset) + C1(V+UVoffset)
G0 = C0(Y0+Yoffset) + C3(U+UVoffset) + C2(V+UVoffset)
B0 = C0(Y0+Yoffset) + C4(U+UVoffset)

R1 = C0(Y1+Yoffset) + C1(V+UVoffset)
G1 = C0(Y1+Yoffset) + C3(U+UVoffset) + C2(V+UVoffset)
B1 = C0(Y1+Yoffset) + C4(U+UVoffset)

CSC1 operation of PXP, it is request a data format U, Y0, V, Y1.

But our camera output only Y0, U, Y1, V.

So, RGB conversion result will be the result of making a mistake as shown below.

U data set Y0 in formula.

Y0 data set U in formula.

V data set Y1 in formula.

Y1 data set V in formula.

So befor PXP, byte order change from YU to UY and YV to VY by CPU and run PXP,

First, Byte order, Y0 - U and  Y1 - V, convert by CPU, from Y0, U, Y1, V to U, Y0, V, Y1.

And run CSC1 by PXP.

RGB conversion result will be correct. so LCD preview seems good color.

Easy way to test it, please use csi_ccir656 sample of MCUXpresso SDK.

It is use YUV -> RGB conversion by PXP CSC1.

EVK camera module output UY0VY1 data so it isn't need byte swap.

So .swapByte member set false.

pxp_ps_buffer_config_t psBufferConfig = {
    .pixelFormat = kPXP_PsPixelFormatUYVY1P422,
    .swapByte = false,
    .bufferAddrU = 0U,
    .bufferAddrV = 0U,
    .pitchBytes = DEMO_CAMERA_WIDTH * APP_BPP,
};

Please try to set .swapByte to true and run it.

Best regards,

Ishii.

[victorjimenez · Accepted solution]

Hello Ishii, 

The reference manual has some problems. WB_SWAP is actually located in bit 6 of the register, not bit 5. This has been fixed already, you can download the newest version from the product page.

Within the SDK, after calling "PXP_SetProcessSurfaceBufferConfig(APP_PXP, &psBufferConfig); function add the following instruction APP_PXP->PS_CTRL_SET |= 1<<6u. This will be fixed in future releases of the SDK as well. 

Regards,
Victor 

[takayuki_ishii]

Hello Victor,

Thank you for your response.

I investigated your answer and confirmed that it was correct.

I modify PXP_PS_CTRL_WB_SWAP_MASK and PXP_PS_CTRL_WB_SWAP_SHIFT in MIMXRT1062.h and MIMXRT1052.h as following.

/*! @name PS_CTRL - Processed Surface (PS) Control Register */
/*! @{ */
#define PXP_PS_CTRL_FORMAT_MASK (0x3FU)
#define PXP_PS_CTRL_FORMAT_SHIFT (0U)
/*! FORMAT
* 0b00100..32-bit pixels (unpacked 24-bit format)
* 0b01100..16-bit pixels
* 0b01101..16-bit pixels
* 0b01110..16-bit pixels
* 0b10000..32-bit pixels (1-plane XYUV unpacked)
* 0b10010..16-bit pixels (1-plane U0,Y0,V0,Y1 interleaved bytes)
* 0b10011..16-bit pixels (1-plane V0,Y0,U0,Y1 interleaved bytes)
* 0b10100..8-bit monochrome pixels (1-plane Y luma output)
* 0b10101..4-bit monochrome pixels (1-plane Y luma, 4 bit truncation)
* 0b11000..16-bit pixels (2-plane UV interleaved bytes)
* 0b11001..16-bit pixels (2-plane UV)
* 0b11010..16-bit pixels (2-plane VU interleaved bytes)
* 0b11011..16-bit pixels (2-plane VU)
* 0b11110..16-bit pixels (3-plane format)
* 0b11111..16-bit pixels (3-plane format)
*/
#define PXP_PS_CTRL_FORMAT(x) (((uint32_t)(((uint32_t)(x)) << PXP_PS_CTRL_FORMAT_SHIFT)) & PXP_PS_CTRL_FORMAT_MASK)
#define PXP_PS_CTRL_WB_SWAP_MASK (0x40U)
#define PXP_PS_CTRL_WB_SWAP_SHIFT (6U)
#define PXP_PS_CTRL_WB_SWAP(x) (((uint32_t)(((uint32_t)(x)) << PXP_PS_CTRL_WB_SWAP_SHIFT)) & PXP_PS_CTRL_WB_SWAP_MASK)
#define PXP_PS_CTRL_RSVD0_MASK (0x80U)
#define PXP_PS_CTRL_RSVD0_SHIFT (7U)
#define PXP_PS_CTRL_RSVD0(x) (((uint32_t)(((uint32_t)(x)) << PXP_PS_CTRL_RSVD0_SHIFT)) & PXP_PS_CTRL_RSVD0_MASK)

It is work byte swap and color space conversion.

Best regards,

Ishii.

[takayuki_ishii]

Hello community,

I check the new release SDK 2.10.0.

But it is not fixed this problem yet.

PXP_PS_CTRL_WB_SHIFT define as (5U)  yet both IMXRT1052.h and IMXRT1062.h.

So, API function PXP_SetProcessSurfaceBufferConfig() can't control WB_SWAP bit.

#define PXP_PS_CTRL_WB_SWAP_MASK (0x20U)
#define PXP_PS_CTRL_WB_SWAP_SHIFT (5U)
#define PXP_PS_CTRL_WB_SWAP(x) (((uint32_t)(((uint32_t)(x)) << PXP_PS_CTRL_WB_SWAP_SHIFT)) & PXP_PS_CTRL_WB_SWAP_MASK)

Best regards,

Ishii.

[victorjimenez]

Hello Ishii, 

Thanks for your comments. I validate this internally, this feature didn't make it into the new release of the SDKs. Hopefully, it will be included in the next release. 

Regards,
Victor