i.MX6 IPU color space conversion issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6 IPU color space conversion issue

1,067 Views
fabricio_quiros
Contributor I

Hi everybody,

I am using a custom i.MX6 board and I am working on a color space conversion application. My input image is 1920x1080 in UYVY 16-bit format and my output target image is 1920x1080 8-bit Gray scale. I've already read about the 1024x1024 limitation of the i.MX6 IPU in certain Freescale forums, so I've implemented and adapted the splitting logic recommend in the following link: https://community.freescale.com/message/327055#327055 to my source code. In fact, I've accomplished the respective color space conversion of the input image (Figure 1), but the resulting image (Figure 2), if you guys can noticed, has a sort of black line right in the middle of it. I've been trying to debug this issue, but currently I haven't found any hint about what is going on. So I've come to ask to the Freescale Community if someone has dealt with this issue. Thanks in advance for any help.

pattern.jpg

Figure 1. Input image, resolution at 1920x1080, format 16 bit UYVY.

splitting-test.bmp

Figure 2. Resulting image of the color space conversion, resolution at 1920x1080, format 8 bit Gray scale.

Labels (4)
0 Kudos
2 Replies

521 Views
jimmychan
NXP TechSupport
NXP TechSupport

I just give an idea base on your picture. As I can see, there are two lines, not one. One is at the top, the other is at the middle. I am not sure if you may check the frame buffer or somewhere data feeding has been missed during the conversion. for example : i=0 at the beginning but i=1 in a 'for' loop

0 Kudos

521 Views
fabricio_quiros
Contributor I

Hello,

First of all, thanks for your answer. For the data feeding, I'm using a memcpy function instead of a 'for' loop. Also, I've already checked in my application the input frame buffer before the color space conversion and seems to be right. Although, after the colour space conversion, the output frame buffer is just like the Figure 2 of my first post, I think that seems to be an issue with the splitting logic implemented or the conversion itself. Up next, there is attached the code used to do the color space conversion with the splitting logic.

total_input_width = 1920;
total_input_height = 1080;

input_frame_size = (total_input_width * total_input_height * 2);

processing_input_width = total_input_width - 896;

processing_input_height = total_input_height - 56;

total_output_width = 1920;
total_output_height = 1080;

output_frame_size = (total_output_width * total_output_height * 1)

processing_output_width = total_output_width - 896;

processing_output_height = total_output_height - 56;

memcpy(input_buffer, input_frame, input_frame_size);

// Perform color space conversion

// First task

if (ioctl(fd, IPU_QUEUE_TASK, &task) < 0)  {

    perror("ioct IPU_QUEUE_TASK fail");

    return -1;

}

// Second task

task.input.paddr  += (processing_input_width * processing_input_height * 2);

task.output.paddr  += (processing_output_width * processing_output_height * 1);

if (ioctl(fd, IPU_QUEUE_TASK, &task) < 0)  {

    perror("ioct IPU_QUEUE_TASK fail");

    return -1;

}

memcpy(output_frame, output_buffer, output_frame_size);

0 Kudos