PXP - YUV to RGB conversion

cancel
Showing results for 
Search instead for 
Did you mean: 

PXP - YUV to RGB conversion

Jump to solution
870 Views
tanguyophoff
Contributor I

Hey,

I am trying to use the pxp on a i.MX 6UL (bare metal) to convert YUV images to RGB so I can display them on an LCD screen.

The images are in YUV422 with the BT.601 colorspace, and I am using the default conversion values, as proposed in the i.MX 6UL user manual.

I disabled the LUT, CSC2 and I am not merging AS & PS through the pxp.

I am not sure what I am doing wrong, but the images are not correctly transformed (see images).

It doesn't look like the pixels are all wrong, but rather like the pxp is classifying the pixels. I found some register definitions about a histogram classification algorithm in the user manual, but couldn't find more information about it.

To me it seems like the pxp is using this algorithm to classify the image, rather than just converting it...

How can I disable this classification? Or what am I doing wrong?

If you need more info (like register values), ask me and I'll respond asap!

Any help is appreciated!

ps: The images are taken with my phone, and thus are of rather bad quality... 

Labels (3)
0 Kudos
1 Solution
220 Views
tanguyophoff
Contributor I

I found the issue myself, so I'll post it here for other people!

I dont use the AS with the pxp, but apparently it still tries to fetch data from adress 0x00000000! (not 100% sure about this...) 

So I enabled AS colorkeying and put the low value at 0x0 and the high value at 0xFFFFFF. This will cause every pixel from the AS to be discarded!

As for the Color Space conversion coefficients, I found some values in the linux driver for the pxp (linux-fslc/pxp_dma_v2.c at 4.1-2.0.x-imx · Freescale/linux-fslc · GitHub ), which seem to give nice results!

HW_PXP_CSC1_COEF0 : 0x84ab01f0
HW_PXP_CSC1_COEF1 : 0x01980204
HW_PXP_CSC1_COEF2 : 0x0730079c

A last thing to note is that the pxp uses physical addresses and does not pass through the MMU with virtual addresses. This has 2 implications:

  • You need to calculate the physical address of the buffers yourself.
  • We had some problems with the MMU because the part of memory where are images got stored, were in a cache enabled, write-back mode. Because of this the pxp didn't always get the correct values, because the MMU kept the right values in cache and did not flush it to the memory! We fixed this by moving that buffer to a non-cacheable part of memory.

View solution in original post

0 Kudos
1 Reply
221 Views
tanguyophoff
Contributor I

I found the issue myself, so I'll post it here for other people!

I dont use the AS with the pxp, but apparently it still tries to fetch data from adress 0x00000000! (not 100% sure about this...) 

So I enabled AS colorkeying and put the low value at 0x0 and the high value at 0xFFFFFF. This will cause every pixel from the AS to be discarded!

As for the Color Space conversion coefficients, I found some values in the linux driver for the pxp (linux-fslc/pxp_dma_v2.c at 4.1-2.0.x-imx · Freescale/linux-fslc · GitHub ), which seem to give nice results!

HW_PXP_CSC1_COEF0 : 0x84ab01f0
HW_PXP_CSC1_COEF1 : 0x01980204
HW_PXP_CSC1_COEF2 : 0x0730079c

A last thing to note is that the pxp uses physical addresses and does not pass through the MMU with virtual addresses. This has 2 implications:

  • You need to calculate the physical address of the buffers yourself.
  • We had some problems with the MMU because the part of memory where are images got stored, were in a cache enabled, write-back mode. Because of this the pxp didn't always get the correct values, because the MMU kept the right values in cache and did not flush it to the memory! We fixed this by moving that buffer to a non-cacheable part of memory.

View solution in original post

0 Kudos