• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 360 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Strange shift in a frame on DM355

Gennadiy Kiryukhin
Expert 2800 points

I have come across a very strange tearing/frame shifting during IPIPEing. It does not happen on every frame. But it does happen quite frequently and only when downsizing a frame.

 

There is a tearing in the frame. This frame was captured at 1280x960 (Bayer) resolution and than was resized by IPIPE to 640 by 480 and JPEGed. Some times it gets processed without tearing, sometimes with tearing. However, if I do not resize the frame but IPIPE it to the same resolution, no tearing is observed.

Also, if I capture a bayer frame at 640x480 resolution and IPIPE it without resizing, frame comes out looking fine every time.

In the example above, the frame has one step. However, I have seen frames where shifting increases in steps (see below). No frame division is used.

The problem occurs only when I am trying to downsize (divide by 2) the frame. I have trying reducing IPIPE clock (use divide by 32) with the same result. In my case, the data is read from RAM and written back into RAM. It is unlikely that the problem is due to memory bandwidth since processing without downsizing produces no tearing.

Thank you. 

  • 0
    TI__Intellectual 995 points

    Which device and HW/SW platform do you observe this?

    It seems as if data of the current frame is mixed with data from an older frame. Try increasing # of buffers to see if the problem is still there. Also, does this happen if data comes from the sensor directly?

    Xiangdong

  • 0 in reply to Xiangdong Fu
    Expert 2800 points

    The frame appears to be corrupted by the IPIPE. It happens only when I try to scale down a frame (ex. going from 1280x960 Bayer to 640x480 YUV) and never happens when no scaling is performed (ex. going from 1280x960 Bayer to 1280x960 YUV) . I am only processing one frame. My image sensor operates in snapshot mode producing only one frame (as opposed to video mode where frames come one after another non-stop).  There is one buffer for the IPIPE input containing the bayer frame from the image sensor, and one buffer for the IPIPE output. 

  • 0 in reply to Gennadiy Kiryukhin
    Expert 2800 points

    I am using DM355, DVSDk 3.01. Running on custom board.

  • 0 in reply to Gennadiy Kiryukhin
    TI__Intellectual 995 points

    Thanks for the clarification. Can you please try a standalone test where you read a 1280x960 picture from a file and resize it to 640x480 using the resizer?

    In addition, it will be useful if you can provide a register dump of your IPIPE and Resizer settings.

    Regards,

    Xiangdong

  • 0 in reply to Xiangdong Fu
    Intellectual 945 points

    The effect you're seeing seems very similar to a problem I recently encountered. For me the problem was a matter of memory bandwidth: I had (unknowingly) configured the resizer to operate at it's maximum speed (config.clk_div = 0), and while this worked fine in simple tests, once I started doing mpeg encoding I would get a tearing effect. I should note that in my system I was dealing with YUV for both input and output, so I had no color corruption, just shifted rows. In your case it seems that your bayer->YUV conversion is also being affected along with the resize itself.

  • 0 in reply to Josh Watts
    Expert 2800 points

    The color mess-up is the same I have seen before (the whole picture would have magenta look to it with a whole bunch of noise; that problem was due to initialization of the PLL in the image sensor resulting in incorrect Bayer format). That effect happens when the Bayer pattern in in the data does not line up with what is defined in IPIPE. It appears as if at some point IPIPE starts processing the end of the previous row as it was the beginning of the new row. Since previous row has an opposite Bayer pair (BG  vs. GR) this results in a messed up color.

    The strange thing is I don't see the problem if I don't downsize the image. Although you would think downsizing the image would be easier on the bandwidth since there is less data at the output of the IPIPE. I also tried reducing clock down to 1/32 still had the problem. Go figure...

    Once I get the IPIPE register configuration, I will post it.