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

Picnic cannot show 32-bit uncompressed BMP files

levicki
Valued Contributor I
439 Views
In version 7.0.2.048 of UIC samples, Picnic application cannot deal with 32-bit BMP and 32-bit advanced BMP image format -- it shows empty image, and in file open dialog the preview does not work.

I have attached two test images saved from Photoshop which demonstrate the problem. In my opinion, developers working on Picnic application and BMP decoder should have already had and used such test images during development.

Moreover, I looked at the UIC BMP decoder source code and found some other potential problems as well:
[cpp]    nchannels = m_bmih.biBitCount >> 3;

if(nchannels == 0)
return ExcStatusFail;
[/cpp]
If biBitCount is 16, this will result in nchannels evaluating to 2, and decoder will proceed allocating and initializing (and later attempting to load data) even though 16-bit formats are not supported.
[cpp]    case 1:  colorSpec.SetEnumColorSpace(Grayscale); break;
[/cpp]
8-bit BMP format contains palette, and that palette can consist of any 256 colors out of 16,777,216 colors. Therefore, setting image colorspace to Grayscale is totally wrong.

0 Kudos
1 Solution
PaulF_IntelCorp
Employee
439 Views
Hello Igor,

I have filed a bug requesting a change to the behavior of picnic so it is consistent with standard practice.

Paul

View solution in original post

0 Kudos
5 Replies
Vladimir_Dudnik
Employee
439 Views
I think the picture is get from file right, but because alpha channel contain only zeros, what means fully transparent pixels,that's what you see in picnic applicaton window.

Vladimir
0 Kudos
levicki
Valued Contributor I
439 Views
Vladimir,

Chris Cox of Adobe Photoshop fame says that BMP specification supports an extra channel (alpha channel) but the specification itself does not assign any meaning to the channel content -- in other words, it is not transparency/opacity data by default, and different programs can (and do) use it for different purposes.

In the sample file test32_advanced.bmp with extended header, the alpha channel bit mask in the header is set to zero, therefore it is clear that the channel should be ignored, and that only R, G, and B values should be used to display image.

In the sample file test32.bmp there is no such information, because it uses the shorter header version without R, G, B, and A channel bit masks. For such file, the only way (the way Photoshop and many other applications are doing it) is to scan the whole alpha channel, and use it only if it has non-zero values.

It is worth noting that Adobe Photoshop saves those 32-bit (and some 16-bit) BMP files with an older version of bitmap header (V3) which is no longer documented on MSDN. It can be recognized by header size field. More info can be found here.

Finally, I have attached another sample image, this time with alpha channel that has some data.
0 Kudos
PaulF_IntelCorp
Employee
440 Views
Hello Igor,

I have filed a bug requesting a change to the behavior of picnic so it is consistent with standard practice.

Paul
0 Kudos
levicki
Valued Contributor I
439 Views
Thank you Paul. What about the BMP decoder code fragments I outlined as potentially problematic? Should I file a bug with Premier Support for code samples?
0 Kudos
PaulF_IntelCorp
Employee
439 Views
Hello Igor,

Just a note to let you know that your bug request has been converted into a feature request for consideration in the next major release of the IPP library.

You may submit bug notifications and feature requests on the forum or via Premier.

Regards,

Paul
0 Kudos
Reply