Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

ippiLUVToRGB_32f_C3R returns incorrect results, bug?

yakov_galka
Beginner
596 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
596 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.

0 Kudos
Sergey_P_Intel1
Employee
596 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.

0 Kudos
yakov_galka
Beginner
596 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

0 Kudos
Sergey_P_Intel1
Employee
596 Views

Thank you. 

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

Regards,

Sergey. 

0 Kudos
Gennady_F_Intel
Moderator
596 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.

 

0 Kudos
yakov_galka
Beginner
596 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

0 Kudos
Sergey_P_Intel1
Employee
596 Views

Sorry,

It should be 8.2

Regards,

Sergey.

0 Kudos
Reply