Size of UIC jpeg codec

[Mikael_Grev]

Hello,

I just thought I'd ask if it's expected that a UIC barebones statically linked .dll should be around 6MB? I expected it to be much smaller since 6MB for a codec is quite a lot IMO.

I am using the statically linked single threaded version (*_l.lib). I only use the UIC classes needed for the codec. As a dynamically linked version the .dll is about 150K, so I gues the rest is linked-in methods.

Is there any way to reduce the size? Like limiting it for only some kinds of processors or something?

Would using the IJG as a start mean a smaller .dll? Would it have the same performance as UIC?

Cheers,
Mikael

[Ying_H_Intel]

Hello Mikael,

I'm afraid it istruethat if statically linksingle threaded version.
Yes,you mayshrinkthemforspecial processor.

But Have you tried to build a custom dll based onserial static library (*_l.lib), then link the custom dll with the UIC jpeg dll?

For custom dll build, please refer to
http://software.intel.com/en-us/articles/intel-integrated-performance-primitives-code-samples/=>MAIN - Custom DLLs and Static Libraries - advanced-usage\linkage\custom[dll|so|lib

or do you develop following exe program based on the uic_jpeg.dll, like picnic.exe, then you may link the *_l.lib at this time?

If both are not suitable for your case, you may try the one
MAIN - Using Merged Static Libraries - advanced-usage\linkage\mergedlib

You can use IJG, butthere are some supported feature and multithread performance difference between them, please read: . http://software.intel.com/en-us/articles/intel-integrated-performance-primitives-intel-ipp-jpeg-sample-and-performance-faqs/?wapkw=(jpeg)

Hope it helps
Regards,
Ying H.

[Mikael_Grev]

Just to be clear. I create a .dll/.dylib and dynamically link it to my app. That .dll/.dylib should be totally self contained though and thus when I build it I use static linking. It is the size of this .dll/.dylib I want to be much less than 6 MB. It's only purpose is to compress and decompress JPEG from memory to memory and this only to and from RGBA 8_8_8_8.

The .dll/.dylib should be single threaded but if it makes sense size vs. performance wise I want it to run faster on more modern CPUs.

> But Have you tried to build a custom dll based onserial static library (*_l.lib), then link the custom dll with the UIC jpeg dll?

I read in one of your documents that the linker will only statically link in (copy in) the functions actually used to the output .dll. And as such my statically linked .dll/.dylib should have only the IPP functions that the custom "Jpeg only" UIC source code I have (I have removed all non-jpeg related code from UIC). Or am I wrong?

Also, I can note that there's not many IPP functions called from the UIC code at all. I guess that those functions call other functions though, and that makes it very hard to create a custiom .dll since I don't really know which functions are being called.

Again, though, I thought the linked too care of this and essentially removed all the dead code (as in uncalled functions).

> or do you develop following exe program based on the uic_jpeg.dll, like picnic.exe, then you may link the *_l.lib at this time?

I don't understand what you mean by this.

> If both are not suitable for your case, you may try the one
> MAIN - Using Merged Static Libraries - advanced-usage\linkage\mergedlib

The merged ones doesn't seem to be supported on OS X?

> You can use IJG,...

The question is if it uses less IPP functions that UIC? If not the resulting outputed size should be the same, right? Also, it sees there's only a build for ia32, does this mean it is unsupported on 64 bit?

I only use standard RGB/ARGB jpeg with no IPP threading so I guess IJG should be OK functionality wise.

[Mikael_Grev]

Bump. Please.