Deinterlacing frames...

[Paulo_César_B_]

Hey,

I get interlaced frames of an IP camera. So, I want to deinterlace them. The IPP has various functions to deinterlace the frame.

How can I find out what function I should use? Or all do the same thing but with different qualities?

If all do the same thing with different qualities. Which one has better quality and which is the fastest?

I will deinterlace each frame separately.

About how to use, I've only one doubt.

For example, in the legacy samples I found: 

ippStatus = ippiDeinterlaceFilterTriangle_8u_C1R(pSrc, iSrcStep, pDst, iDstStep, size, 128, IPP_LOWER | IPP_UPPER | IPP_CENTER);

I understand how use, it's ok, but I don't understand this:

size.width  = pSrcPlane->m_size.width * pSrcPlane->m_iSamples * pSrcPlane->m_iSampleSize;
size.height = pSrcPlane->m_size.height;

The "size.width" calculation...

Is this can work: size.width = size.width * step; ????

Best regards,

[Sergey_K_Intel · Accepted solution]

Hi Paolo,

You can try any of them.

Regarding steps and widths, please remember, that steps are measured in bytes, but ROI widths - in pixels. In this case, the ROIs for, say, 640x480 frames are always { 640, 480 } regardless of pixel format (size). While the steps are different. They can be 640 bytes for 1-channel images, or 640 x 3 = 1920 for 3-channel images. Moreover, if we use aligned image buffers - for example, we want each our line of 2D array to start at 32 byte-aligned address - i.e. images with line padding, the step can be non-divisible by image ROI width.

So, size.width * step doesn't work. In the code above you can write size.width = pSrcPlane->m_size.width, because for 1-channel 8u image m_iSamples = m_i_sampleSize = 1.

[Paulo_César_B_]

Thank you very much! Now I understand, but I'm still with two doubts.

The deinterlace functions are deprecated in Ipp 8.2, what can I use instead of them?

Seconds, I don't have experience with this algorithms, I want know what is faster and what have a better result.

Best regards,

[Sergey_K_Intel]

Paulo,

It's hard to say now which is better, because we stopped working with these functions years ago. If you have ready-to-use framework, i.e. "image read->deinterlace->image write" pipeline, you can do the quality/performance experiments by yourself.

Regarding "deprecation", there is no matter to worry about, because in any case the deprecated functions will be accessible through IPP package or from IPP web page.

With this deprecation message we just marked functions which were developed for IPP software video codecs (aka UMC), which are not released now. So, the deprecated functions will unlikely be optimized for further CPU architectures, until we get strong arguments to do that (e.g. from customer response,s surveys, or these functions will be included into other modern software products).