- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you.
It's an IPP issue. Use IPP 8.0, pls.
Regards,
Sergey.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry,
It should be 8.2
Regards,
Sergey.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page