Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
6670 Discussions

ippiLUVToRGB_32f_C3R returns incorrect results, bug?

yakov_galka
Beginner
327 Views

Running this code with IPP 7.1:

static const int w = 11, h = 11;
static const IppiSize roi = {w,h};
static const IppiSize roi3 = {w*3,h};

Ipp8u src8[w*h*3] = {
	128,128,128,118,118,118,128,128,128,  0,  0,  0, 29, 29, 29,  0,  0,  0, 71,  0,  0,132,  0,  0, 56,  0,  0,  0,  0,  0,  0,  0,  0,
	126,126,126,110,110,110,119,119,119, 73, 73, 73,106,106,106, 32, 32, 32,163,  0,  0,233,  0,  0, 94,  0,  0,  0,  0,  0,  0,  0,  0,
	128,128,128,128,128,128,150,150,150, 62, 62, 62, 45, 45, 45,  0,  0,  0, 39,  0,  0,118, 30,  0, 55,  0,  0,  0,  0,  0,  0,  0,  0,
	 90, 90, 90, 43, 43, 43, 94, 94, 94, 72, 72, 72,252,252,252,  0,  0,  0,101,101,  0, 68, 68,  0,118,118,  0, 22, 30,205,  0,  0,  0,
	106,106,106,194,194,194, 45, 45, 45,187,187,187,255,255,255,247,247,202,179,179,  0,185,185,  0,  0,  3,117,  0,  9,225,  0,  6,113,
	 25, 25, 25,127,127,127,  0,  0,  0,118,118,118,198,198,198,113,113, 52, 61, 61,  0,174,174,  0,  0,  8,161,  0,  7,151,  0,  6,113,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  7,135,  0,  0,  0,
	240,  0,205,254,  0,219,254,  0,219,254,  0,220,254,  0,220,254,  0,220,254,  0,220,254,  0,220,254,  0,220,254,  0,219,243,  0,210,
	240,  0,205,254,  0,219,254,  0,219,255,  0,220,255,  0,221,255,  0,221,255,  0,221,255,  0,221,255,  0,219,254,  0,219,243,  0,210,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
	  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
};

float src[w*h*3], tmp[w*h*3], dest[w*h*3];
int step = w*3*sizeof(float);
ippiScale_8u32f_C1R(src8, w*3, src, step, roi3, 0, 1);

ippiRGBToLUV_32f_C3R(src, step, tmp, step, roi);
ippiLUVToRGB_32f_C3R(tmp, step, dest, step, roi);

double norm = 0;
ippiNormDiff_Inf_32f_C1R(src, step, dest, step, roi3, &norm);

I expect src and dest be almost identical, but they differ significantly (norm == 107374176.00000000, which is greater than the [0,1] range of RGB data). Looking at dest, I see that half the values are -107374176. Here are the first few values of dest:

[0]: 0.501961112, [1]: 0.501960814, [2]: 0.501960516,
[3]: 0.462745398, [4]: 0.462745130, [5]: 0.462744951,
[6]: 0.501961112, [7]: 0.501960814, [8]: 0.501960516,
[9]: 0.000000000, [10]: 0.000000000, [11]: 0.000000000,
[12]: -107374176., [13]: -107374176., [14]: -107374176.,
[15]: -107374176., [16]: -107374176., [17]: -107374176.,
[18]: -107374176., [19]: -107374176., [20]: -107374176.,
[21]: -107374176., [22]: -107374176., [23]: -107374176.,
[24]: -107374176., [25]: -107374176., [26]: -107374176.,
[27]: -107374176., [28]: -107374176., [29]: -107374176.,
[30]: -107374176., [31]: -107374176., [32]: -107374176.,
[33]: 0.494117767, [34]: 0.494117677, [35]: 0.494117856,
[36]: 0.431372792, [37]: 0.431372553, [38]: 0.431372404,
[39]: 0.466667026, [40]: 0.466666609, [41]: 0.466666490,
[42]: 0.286274731, [43]: 0.286274493, [44]: 0.286274403,

I did the same with Ipp16u data type, and everything is OK (norm == 3.0 out of 65535).

Please verify my interpretation that this behavior is indeed incorrect, and if so, let me know if the bug (?) is fixed in IPP 8.0.

Thanks,
Yakov Galka

0 Kudos
7 Replies
yakov_galka
Beginner
327 Views

Addendum: I understand that the value -107374176 is simply what was there in the uninitialized dest. That is, ippiLUVToRGB seemly left parts of the image intact. My question, however, still holds: why the composition of ippiRGBToLUV↔ippiLUVToRGB is not an (approximate) identity, which I believe it should be?

Note: I blame ippiLUVToRGB rather than ippiRGBToLUV because the later seems, by manual inspection, to give correct results.

Sergey_P_Intel1
Employee
327 Views

Hi, Yakov.

I'm owner of LUV functions. Pls, explaine what is going wrong. Present me input pixel (LUV) and wrong output pixel(RGB)  

regards,

Sergey.

yakov_galka
Beginner
327 Views

Dear Sergey,

I cannot give you a value of a single pixel, because the behavior of the function depends on where exactly that pixel is located within the array. However, to make it easier to see the problem, I shortened the above example to the following:

	static const IppiSize roi = {2,1}, roi3 = {6,1};
	static const int step = 6 * sizeof(float);
	 
	const float src[6] = {0.000000000, 0.000000000, 0.000000000, 29.2133636, 96.0316086, 20.7148438};
	float dest[6];
	
	ippiSet_32f_C1R(-6.283185, dest, step, roi3); // fill dest with deterministic junk
	ippiLUVToRGB_32f_C3R(src, step, dest, step, roi);

The second pixel has the LUV value of (29.2133636, 96.0316086, 20.7148438), but the LUVToRGB does not write anything back for that pixel, so the RGB value I get, in this specific example, is (-6.28318501, -6.28318501, -6.28318501).

The result in dest is:

	{0.000000000, 0.000000000, 0.000000000, -6.28318501, -6.28318501, -6.28318501}

While the expected result, up to numeric imprecision, is:

	{0.000000000, 0.000000000, 0.000000000, 0.278431386, 0.000000000, 0.000000000}

Sincerely,
Yakov

Sergey_P_Intel1
Employee
327 Views

Thank you. 

It's an IPP issue. Use IPP 8.0, pls.

Regards,

Sergey. 

Gennady_F_Intel
Moderator
327 Views

the problem has been  fixed and the fix of the problem available in the latest IPP 8.1.    You can get the evaluation version of IPP ( 30 days ) and let us know the results.

 

yakov_galka
Beginner
327 Views

Dear Sergey and Gennady,

I have upgraded to IPP 8.1, but the issue was not fixed. I get the same incorrect results as I described above.

Yakov

Sergey_P_Intel1
Employee
327 Views

Sorry,

It should be 8.2

Regards,

Sergey.

Reply