ippiLUVToRGB_32f_C3R returns incorrect results, bug?

[yakov_galka]

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

[yakov_galka]

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]

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]

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]

Thank you. 

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

Regards,

Sergey. 

[Gennady_F_Intel]

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]

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]

Sorry,

It should be 8.2

Regards,

Sergey.