UIC decoding: questions, problems, etc...

UIC decoding: questions, problems, etc...

I have some questions regarding UIC.

1. I tried including #include "uic_dds_dec.h" and it complains about the lack of DDS namespace. It seems that the uic_dds_dec.h should include it (or what should be included should be described in more detail):

#ifndef __UIC_DDS_H__
#include "uic_dds.h"

2. Microsoft compiler is throwing C4291 on uic_new.h:

uic\\src\\core\\uic\\include\\uic_new.h(50) : warning C4291: 'void *operator new(size_t,const UIC::NewBuffer &)' : no matching operator delete found; memory will not be freed if initialization throws an exception

Is it safe to ignore that warning (I presume not)?

3. Are those DLL files compiled with CPU dispatching, if so for what CPUs?

4. Are those DLL files standalone or do they require IPP (or compiler) DLLs? If so, which ones?

5. Can UIC be used statically and if so how?

6. I am writing image viewing application and I intend to support BMP, DDS, JPEG, and PNG image formats. I have a single user Parallel Studio license. What are the terms for redistributing the binary files needed for my application to run?


29 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Igor,

thanks for your comments and questions. Do you use the latest IPP 6.1 update 4 sample package?

1. We will investigate and fix this if it is an issue

2. It is safe to ignore this warning in that particular case. UIC new operator developed to avoid memory problems when allocation done on application heap but deallocation happpens from UIC DLL heap. So, when you create UIC objects in application you need this operator to allocate memory from UIC DLL heap because at object destruction time internal memory will de deallocated from UIC DLL heap.

3. UIC DLL linked with static not threaded IPP libraries, so all cpu-dependend code included into UIC DLL and will be dispatched automatically.

4. UIC DLL designed to not depend from IPP. They already include IPP functions inside.

5. Currently UIC sample designed to build UIC as a DLL libraries. The sample is available in source code form, so you are free to modify it to be static library. Although we did not test that and will not provide technical support for modified version.

6. Please refer to IPP Sample EULA document for license questions.


Hi Igor!

Toeliminateannoying C4291 warning, please correct code in uic_new.h:

inline void operator delete(void*, size_t, const UIC::NewBuffer &) {}


inline void operator delete(void*,const UIC::NewBuffer &) {}

This code was not intended to be called in any practical case, because corresponding version of new operatoris intendedfor UIC internal core needs (I mean arrays allocation byNewArr template function) and exceptions are not used in UIC core objects constructors(because it's a bug to throw exceptions from DLLs).

Soit was not seriously dangerous actually. But warning can be really annoying.



Hello Vladimir,

I am using Parallel Composer update 5 and I re-downloaded samples two days ago.

1. It is not such a big issue but it should either have that included or the documentation should mention that you need to include uic_dds.h before including uic_dds_dec.h.

2. Is that operator used if I perform for example "new JPEGDecoder"? Is Mikhail's fix correct?

6. I did but I do not understand it clearly. Legal English and such.

I have additional questions:

1. How to force UIC to decode all picture formats to 24-bit RGB?

2. Is it possible to provide own buffer and if so, how?

I am asking this because I would like to write directly to video driver buffer to improve texture upload speed.

3. If those are unified image classes, why there is no sample which shows how to use them in a unified manner? For example:

BaseImageDecoder *decoder = NULL;

switch (imagetype) {
case BMP:
	decoder = new BMPDecoder;
case JPEG:
	decoder = new JPEGDecoder;
case XYZ:
	decoder = new XYZDecoder;
	// ...

Thanks in advance for your help.


we'll definetely fix issue with uic_dds_dec.h file in future releases or updates.

Mikhail is our lead UIC API and JPEG2000 codec developer, his comment is correct.

For licensing question you might want to review an answer provided our technical consulting engineer in the thread UIC Licenseon this forum.

You can specify desired output format like it implemented in UIC samples, for example, jpeg.cpp :

in_color = colorSpec.EnumColorSpace();

case 1: out_color = (in_color == Unknown) ? Unknown : Grayscale; break;
case 3: out_color = (in_color == Unknown) ? Unknown : RGB; break;
case 4: out_color = (in_color == Unknown) ? Unknown : CMYK; break;
default: out_color = Unknown; break;


Note, there are some combination when it is not possible to convert compressed data to RGB24 format. In that case decoder will return error.

It is possible to specify your own destination buffer. You need to use image.Attach() method instead of image.Alloc().

And finally, yes UIC add some unification for image codecs butalso leave you enough level of control to access codec specific parameters and so is not completely unified.



Thanks for the correction, will modify the header file to avoid the annoying warning.

Vladimir, Mikhail,

1. Could you please outline steps between calls to ReadHeader() and ReadData() which are necessary to set up output format to 24-bit RGB regardless of input image type (BMP/JPEG/PNG)?

2. Can I assume that the UIC can convert say b&w, 8-bit palettized input or 16-bit gray to 24-bit RGB or attempting that will fail?

3. If it fails with an error, which function will fail? Conversion setup or ReadData() or somewhere else?

4. Is there some list of those "impossible" conversions in the documentation?

5. Can you please give more details about using own destination buffer (Attach() method)?

6. How to select best JPEG decoding quality?

7. What are format specific steps (i.e. those not necessary for BMP) for JPEG, JPEG2000, PNG and DDS?

8. How does UIC handle DDS with respect to mipmap levels? Does it work only with base texture level or with all of them?

My goal is to have a single image decoding function which gets a decoder pointer based on the image type detected. That function should always decode image to user supplied buffer in 24-bit RGB format or fail if it cannot do it.

Any help and additional examples/code snippets are very appreciated.


we do not support mip-maps in DDS in current version. I would recommend you to look through UIC sample application on most of you question about how to call ReadHeader or ReadData, how to set output image color and so on.



I really do not think that wading through a heap of sample source code is the best way to learn how to use a library or an API, much less a hierarchy of abstract and/or derived C++ classes.

I have to say that I am disappointed with UIC documentation in much the same way I am disappointed with IPP documentation -- they both mostly consist of a (machine generated?) list of functions with brief parameter description. In most cases that is not enough to figure out how to use the particular function properly.

Let me give (somewhat exaggerated) example -- if I write a function, lets call it function_xyz(), and if I were to document it, then writing:


function_xyz(int strength, some_type something)

function_xyz() does xyz with something where:

strength - xyz strength
something - element of some_type upon which xyz will be applied


Doesn't help at all, because I have not explained anything that was not already obvious from the function and the parameter names.

With all that out of the way, I would still prefer if one of you guys could provide direct answers to my questions in the previous message because some of them really can't be answered by looking at the source code and existing documentation.

Finally, the samples really do not use unified feature of those classes -- they implement image decoding for each format separately, that is not what I want, and I believe that there is no point in providing unified classes if you don't show how to use them in a unified manner.




the reality is that documentation might not answer all possible questions someone may have. From other hand samples are available in source form, so if there is an interest thatshould bepossible to learn some details from sample applictions.

I also noticed that even having comprehensive documentation on IPP functions there are cases when it is not taken into account. You may see many examples of this on the forum.

Having said that it does not mean we will not improve documentation in future versions. Of course we will. Thank you for your question it definitely will help in extending UIC documentation in future.

You also should notice that unification in image codecs is not obvious task. Think about howone will unify in single application three different usage models, like simple displaying photo images (which are mostly 8-bits per channel) with scientific image processing on 32-bit floating point images and also with medical image processing (mostly done with 16-bit integer data)? So, the question is what kind of unification you are looking for?



I am aware that there is no such thing as perfect documentation. However, for IPP (and UIC to some extent) it seems as if the authors are assuming that everyone using those libraries will have the same level of expertise as themselves when it comes to codec specifics, ITU standards, algorithms, etc. That is the main problem I see with the documentation.

You see, when a developer choses to use a library, it is usually because it will save them tremendous amount of time and effort, and let them focus on the functionality of whatever they are developing instead.

If the documentation cannot help them to utilize the library without having to analyze sample source code, then a part of the commodity that the library should have brought is already lost, and it is even worse if code samples do not show expected usage model or if they are missing alltogether.

Regarding IPP documentation -- many questions on this forum are posted because documentation is lacking. If you remember, I have asked about deinterlacing function (ippiDeinterlaceMotionAdaptive_8u_C1) usage sample in this thread, and I never got an answer.

Regarding unification, I believe I explained my needs but I will try again:

I am writing an image viewer application which is partially hardware accelerated using OpenGL. I use OpenGL for fast panning (without tearing thanks to VSync) and zooming, and I am displaying the image as a 2D texture.

That texture is always 24-bit RGB. I would like to support at least BMP, JPEG and PNG formats initially. UIC seems like the best choice for the task at hand.

- At the moment, I am not interested in handling images with more than 8 bits per component.
- I am also not interested in handling floating point formats at the moment.
- I am interested in displaying monochrome, 4-bit and 8-bit palletized color or grayscale images -- BMP, PNG, and grayscale JPEG.
- I am interested in displaying truecolor images (BMP, PNG, JPEG).
- I am also interested in displaying 16-bit color images (BMP with different RGB packing like R5G5B5, R5G6B5, R4G4B4, etc) but that is not a priority -- it would be nice if it could work, but if UIC doesn't support conversions to 24-bit RGB then it doesn't matter.

So, to summarize I need the following:

1. 24-bit RGB output regardless of file format and bit depth
2. Output to user supplied buffer
3. Best possible decoding quality (subsampling/idct/quantization) for JPEG

What I would like to see implemented in UIC in the future is support for OpenEXR format (HDRI), and for RAW camera images (Canon's .CR2 and Nikon's NEF at least) -- at least the ability to extract embedded JPEG preview image if not demosaicing and full color/white balance processing. Support for Adobe DNG wouldn't hurt either.



Hi Igor,

your points as usual are vaild and valuable andkeep us focused on improving product. Unfortunately at the moment we do not have that level of unification across UIC codecs, so it is something we will consider to implement in future version.

Also, I would like torefer you to UIC Picnic application which demonstrate similar level of unification (although achieved on application level not on codec level).

And if you noticed, in UIC sample we use external memory for UIC codec,like for example bmp.cpp file:


status = decoder.ReadData(imageCn.Buffer().DataPtr(),dataOrder);

here, imageCn is UIC image, and we attach external memory buffer to it before passing to decoder.



Unfortunately I still cannot figure out neither from your explanation nor from the code samples how to load 8-bit BMP as 24-bit RGB using UIC? Is it possible at all or I need to load and convert using some other function? If it isn't possible to convert during decoding I really have trouble seeing the advantages of UIC over other libraries.

Furthermore, here are some potential issues with the bmp.cpp sample code from Picnic application:

  default: out_color = Unknown; // or any other line with Unknown in it

Shouldn't it be:

  default: out_color = UIC::Unknown; // just to be safe?

Because in WinIoCtl.h (included by Windows.h) there is an enum:

typedef enum _MEDIA_TYPE {
    Unknown,                // Format is unknown

Moreover, the following code:

  ImageEnumColorSpace in_color;
  ImageEnumColorSpace out_color;
  in_color = colorSpec.EnumColorSpace();

  case 1:  out_color = (in_color == Unknown) ? Unknown : Grayscale; break;
  case 3:  out_color = (in_color == Unknown) ? Unknown : BGR;       break;
  case 4:  out_color = (in_color == Unknown) ? Unknown : BGRA;      break;
  default: out_color = Unknown;                                     break;


Shows rather poor programming style and lack of logic expression optimization effort (it looks like copy/paste programming), I would personally write the above code like this:

	ImageEnumColorSpace out_color = UIC::Unknown;

	if (colorSpec.EnumColorSpace() != UIC::Unknown) { // if in_color not unknown
		switch (nOfComponents) {
		case 1:
			out_color = UIC::Grayscale;
		case 3:
			out_color = UIC::BGR;
		case 4:
			out_color = UIC::BGRA;


That is, if you care about teaching people how to write clean, simple, optimized code.

Finally, this line:

  case 1:  out_color = (in_color == Unknown) ? Unknown : Grayscale; break;

Assumes that 8-bit single component BMP is grayscale when it can be palletized 256 color image. Enumeration doesn't even have "Palette" as a choice, and even if this doesn't affect the decoding it is still confusing.


Let me add that the BMPDecoder ReadHeader() function is failing on 32-bit BMP files saved using Advanced Modes (X8 R8 G8 B8) preset from Photoshop. It seems that BMPDecoder is ignoring BITMAPFILEHEADER member bfOffBits which is correctly set by the Photoshop.

Just so you know, there is also a problem with BMP files which have negative height (vertically flipped images) -- ImageSamplingGeometry is returning positive height, wrong origin (0,0), and image is decoded upside down. It should either flip the image, and return positive height and origin of 0,0 or decode as is and return negative height and origin of 0, +height. I would prefer flipping during decoding because this avoids having to allocate another buffer.

I submitted an issue with Premier Support:

Thanks Igor,

two cases you refer are matter of lack of support in features in our implementation. We will consider to extend BMP support although I would not commit to complete BMP implementation. We more focused on support for JPEG/JPEG2000/PNG and JPEG-XR for future



You should at least support common uncompressed BMP formats otherwise your decoder is totally unusable. As a matter of fact it is unusable for me already since I cannot correctly show flipped images, so I started writing my own BMP decoder.

What is worse, I wanted to use IPP functions for conversion in my decoder, and then I realized that the conversion functions I would need to implement full support for uncompressed BMP formats are missing as well. Check the other two threads I started today to get an idea what else is missing.


with all respect to you, I see the difference between toatally unusable and totally unusable for some particular project. Having support for 8-bits grayscale and 24-bits color BMP images is enough to demonstrate benefits we provide in JPEG and JPEG2000 codecs. And as I said before we will consider possibility to improve BMPsupport in UIC.



You can perhaps argue about the meaning of "totally unusable" when it comes to supported bit-depths and compression formats, but if you decode the picture upside down without providing any hint of what you did, that pretty much makes it totally unusable for everyone, not just for me.

Finally, I must say that I am disappointed by UIC so far -- I don't see the "unified" part neither in the programming interface nor in the wild differences in the level of support for various image formats.

I'm not going to argue about meaning of "totally unusable" term. It was proven that UIC is usable and there are also some limitations. It work pretty well for the majority of true-color BMP images.

Thanks for your feedback, that is exactly what we expect from our customers and this forum seems to be just right way to learn our customers experience with product.



Regarding BMP images, I spent yesterday's afternoon coding BMP support from scratch and I finished it.

With 5KB of plain C source code my own BMP decoder supports:

- 1-bit bitonal images
- 4-bit color and grayscale images
- 8-bit color and grayscale images
- 16-bit color (R5G5B5, R5G6B5, R4G4B4)
- 24-bit color
- 32-bit color (basic, and advanced with channel masks specified)

All of them are properly decoded regardless of whether they have negative or positive height.

Unthreaded, unoptimized, plain C code takes between 84ms (1-bit) and 178ms (32-bit) to decode 6000x4711 image.

Please don't tell me Intel couldn't have done the same.

And I did not told you that.


I know you didn't but your response implied that better BMP support involves a lot of work while it is something a single developer can do in one afternoon.

If you are interested, I can give you my BMP decoder source code to use it as a basis for a proper BMP support in the future.

In the meantime I have more oddities to report:

1. JPEG decoder supports decoding to BGR format, PNG decoder does not -- I have to manually swap channels to get the format I need.

2. PNG decoder RGBA support seems not to be done properly -- if I understand PNG specification correctly, alpha compositing should be done with linear image samples, not with gamma corrected ones.

As far as I know, PNGDecoder::ReadHeader() does not provide gamma information so I cannot undo gamma correction on my own before alpha compositing.

Therefore, compositing should be part of the decoding process which means decoding function should have a parameter which specifies background image for compositing.

3. PNG decoder is slow -- 1,014ms for 6000 x 4711 px truecolor image is too much on a 3.3GHz quad-core Nehalem. PNGDecoder::SetNOfThreads(4) has no effect, PNGDecoder::NOfThreads() always returns 1.

4. JPEG decoder CMYK processing results in wrong, over-saturated colors. You can compare that by looking at the same CMYK image in Photoshop and in Picnic:

Photoshop (correct) rendition is on the LEFT, UIC::JPEGDecoder on the RIGHT.

I have added sample CMYK JPEG image as an attachment. If you load it into Picnic, the left side will look like the right side on the image above, while the right side will be degraded further. If you load it into Photoshop it will look exactly like the image above.

5. PNGDecoder -- 8-bit color images are always decoded as 3 channel images. I don't mind, but I am not sure it is mentioned anywhere in the UIC documentation.

6. JPEGDecoder (I told Jennifer about this) -- if system locale is set to anything other than English (1033) JPEG decoder (or libiomp5md.dll to which it links) opens a console window and prints a warning message. I can't stress enough how broken such behavior is for a dynamically linked library.

If I find more problems I will let you know.


Downloadimage/jpeg CMYK_sample.jpg746.14 KB

There is difference between what single developer can do for fun and what becames a feature of product. And again, we did not extended BMP support because it was enough for our first priority goals. Now, you have submitted feature request and that will be considered for implementation in future versions.

The good thing of UIC is that you can derive from UIC base classes your own implementation of BMP format processor and satisfy your needs before similar functinality will be introduced in UIC.



I was not writing BMP decoder for fun, but because I needed it for my application.

Please take a look at the updated post above, I added a few issues I found during development with UIC.

Thanks again, there are some points I agree with you, they need to be corrected. Was surprized to read about command line window thrown from DLL, never saw such behavior, we will investigate that and I will provide additional info here sometime later.



Should I create issues with Premier Support for the problems I found and listed in the previous post or is posting them here good enough?

I would really like to have some feedback on whether those issues will be fixed and when.

Please feel free to submit issues to Premier Support, especially when you have several ones discussed in single forum thread.


Hi Vadimir,I would like to know if there is any functions in UIC to get the image attributs like width, height, image size, compression, bitcount etc. Hope you can help me on this.Regards,Prabha

Hi Vladimir -

I agree with this request -

Support for Adobe DNG wouldn't hurt either.


Is it possible to add support for compressed DNG - its a part of the DNG standard. Also, DNG can be easily derived from the tiff API - and you already have some compression algorithms.

Compressed DNG would be invaluable for my application!

Leave a Comment

Please sign in to add a comment. Not a member? Join today