Error code ippStsCoeffErr with ippiWarpPerspective

[Scott_Mcmichael]

I am trying to use ippiWarpPerspective and get error code -56 (ippStsCoeffErr) when I pass in non-identity transforms. I found some old threads about this issue but no solutions:

http://origin-software.intel.com/en-us/forums/showthread.php?t=63339
http://software.intel.com/en-us/forums/showthread.php?t=54250&o=a&s=lr&wapkw=%28Architecture+Software+Developer%29

Here is a sample coefficient set that I am passing in to the function as reported by visual studio:

[0][0] 0.99999426951673498
[0][1] -3.0119434616414690e-006
[0][2] 1.9780879024589358e-008
[1][0] 0.00023626541131144098
[1][1] 0.99993458569317439
[1][2] 1.2301679847236111e-007
[2][0] -0.040422124313244316
[2][1] 0.0062414088928023541
[2][2] 1.0

I am pretty sure all the other function inputs are correct since they work with the identity transform. Are there any unstated reqirements of this function that my coefficients violate?

[Chao_Y_Intel]

Hello,

We noticed one related problem reported before. The problem happens because the following check error:

Before transform we need to check the quad polygon convexity and orientation.
double area0 = (quad[3][0] - quad[2][0]) * (quad[0][1] - quad[3][1]) (quad[0][0] - quad[3][0]) * (quad[3][1] - quad[2][1]);
double area1 = (quad[0][0] - quad[3][0]) * (quad[1][1] - quad[0][1]) (quad[1][0] - quad[0][0]) * (quad[0][1] - quad[3][1]);
double area2 = (quad[1][0] - quad[0][0]) * (quad[2][1] - quad[1][1]) (quad[2][0] - quad[1][0]) * (quad[1][1] - quad[0][1]);
double area3 = (quad[2][0] - quad[1][0]) * (quad[3][1] - quad[2][1]) (quad[3][0] - quad[2][0]) * (quad[2][1] - quad[1][1]);

If area0, area1, area2, area3 have different signs that means the specified rectangle is non-convex. Is this problem for your case?

Thanks,
Chao

[Scott_Mcmichael]

I don't think it would affect us if the rectangle is non-convex. We are just trying to compute an approximate transform between two successive images from a video camera.

I guess the way to work around this would be to compute all of the pixel locations manually and then pass them to the IPP remap function but I imagine that will be much slower than the single function call would be.

Scott