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

UIC decoding: questions, problems, etc...

levicki
Valued Contributor I
894 Views

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"
#endif

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?

Regards,
Igor

0 Kudos
28 Replies
Vladimir_Dudnik
Employee
681 Views

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.

Regards,
Vladimir

0 Kudos
Mikhail_Kulikov__Int
New Contributor I
681 Views

Hi Igor!

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

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

to

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.

Thanks,

Mikhail

0 Kudos
levicki
Valued Contributor I
681 Views

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:

[bash]BaseImageDecoder *decoder = NULL;

switch (imagetype) {
case BMP:
	decoder = new BMPDecoder;
case JPEG:
	decoder = new JPEGDecoder;
case XYZ:
	decoder = new XYZDecoder;
	// ...
}
[/bash]
Thanks in advance for your help.

0 Kudos
Vladimir_Dudnik
Employee
681 Views

Igor,

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();

switch(nOfComponents)
{
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;
}

imageCn.ColorSpec().SetEnumColorSpace(out_color);

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.

Regards,
Vladimir

0 Kudos
levicki
Valued Contributor I
681 Views

Mikhail,

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.

0 Kudos
Vladimir_Dudnik
Employee
681 Views

Igor,

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.

Regards,
Vladimir

0 Kudos
levicki
Valued Contributor I
681 Views

Vladimir,

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.

Regards,

Igor

0 Kudos
Vladimir_Dudnik
Employee
681 Views

Igor,

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?

Regards,
Vladimir

0 Kudos
levicki
Valued Contributor I
681 Views

Vladimir,

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.

Regards,

Igor

0 Kudos
Vladimir_Dudnik
Employee
681 Views

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:

imageCn.Buffer().Attach(&dataPtr,dataOrder,geometry);

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

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

Regards,
Vladimir

0 Kudos
levicki
Valued Contributor I
681 Views
Vladimir,

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:
[cpp]  default: out_color = Unknown; // or any other line with Unknown in it
[/cpp]
Shouldn't it be:
[cpp]  default: out_color = UIC::Unknown; // just to be safe?
[/cpp]
Because in WinIoCtl.h (included by Windows.h) there is an enum:
[cpp]typedef enum _MEDIA_TYPE {
    Unknown,                // Format is unknown
...
[/cpp]
Moreover, the following code:
[cpp]  ImageEnumColorSpace in_color;
  ImageEnumColorSpace out_color;
  in_color = colorSpec.EnumColorSpace();

  switch(nOfComponents)
  {
  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;
  }

  imageCn.ColorSpec().SetEnumColorSpace(out_color);
[/cpp]
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:
[cpp]	ImageEnumColorSpace out_color = UIC::Unknown;

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

	imageCn.ColorSpec().SetEnumColorSpace(out_color);
[/cpp]
That is, if you care about teaching people how to write clean, simple, optimized code.

Finally, this line:
[cpp]  case 1:  out_color = (in_color == Unknown) ? Unknown : Grayscale; break;[/cpp]
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.

Regards,
Igor
0 Kudos
levicki
Valued Contributor I
681 Views
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.
0 Kudos
levicki
Valued Contributor I
681 Views
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:
https://premier.intel.com/premier/IssueDetail.aspx?IssueID=584024
0 Kudos
Vladimir_Dudnik
Employee
681 Views
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

Regards,
Vladimir
0 Kudos
levicki
Valued Contributor I
681 Views
Vladimir,

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.
0 Kudos
Vladimir_Dudnik
Employee
681 Views
Igor,

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.

Regards,
Vladimir
0 Kudos
levicki
Valued Contributor I
681 Views
Vladimir,

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.
0 Kudos
Vladimir_Dudnik
Employee
681 Views
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.

Regards,
Vladimir
0 Kudos
levicki
Valued Contributor I
681 Views
Vladimir,

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.
0 Kudos
Vladimir_Dudnik
Employee
597 Views

And I did not told you that.

Vladimir

0 Kudos
Reply