- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i try decompress and compress under ipp jpeg file with jpeg library what is part of linux examples on download pages. But its a 20% slower how jpeglib in linux. Where is problem. Is possible accelerate this process with some jpeg coding and decoding parameters? I use 3.4 Ghz nad result is 20 jpeg/s. Jpeg only have 25kb! I need 15x better performance.
When i create example form memory to memory with fast parameters jpeglib is 5x faster. How do it in ipp?
ipp 4, linux, gcc or icc.
When i create example form memory to memory with fast parameters jpeglib is 5x faster. How do it in ipp?
ipp 4, linux, gcc or icc.
Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
it looks like you use "generic" or PX IPP libraries. Could you please check if it is so?
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, thanks. Could you also tell me what info you can see if you issue Help-About IPP command from menu?
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, IPP uses correct library. I think the key here is that you count process creation time. I think GUI application is loading slower than simple command line application.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks again, we will check this issue. The numbers on IPP www site is about performance comparison of IPP jpeg codec under windows with IJG v6B. According our tests IPP jpeg codec outperforms IJG on windows.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
you are linking with static libraries without specifying the architecture, try including ipp_w7.h after ipp.h
otherwise use the dynamic libraries
this made all the difference for me...
- Fabio
otherwise use the dynamic libraries
this made all the difference for me...
- Fabio
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I saw from the Website that the JPEG decoding is %200 better performance from the IPP website. We are using JPEG decoder in our application and it takes a 2.0 Ghz processor only for %25 CPU performance JPEG decoding of 25fps on our computer.
When we use IPP assmbled machine codes could we expect the CPU perfroamce for the same enviroanment and same conditions to be under %10 CPU perfroamnce.
Note: We are using C compiled IJG Jpeg libraray at the moment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We have done various tests with JPEG-IPP , IJL, IJL-optimized IPP, and previous IJL 1.51 version. The result is obviuous : JPEG-IPP is the best solution in term of speed and cpu usage. Test was done for :
1024 x 768 x 24bit at 40 fps
640 x 480 x 24 bits at 94 fps
On our web site you can find test applications to comptute what we call jepgBandwidth.
SRSR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
we have several JPEG implementations by some reasons:
1 - IJL-IPP, to simplify migration to IPP forIJL users. This implementation not always faster than old IJL because of overhead and not optimal implemenation.
2 - IJG-IPP, it is sample which demostrates how you can speed-up well known JPEG implementation, IJG library (www.ijg.org).
3) JPEG-IPP, it is our fastest JPEG codec, because of optimal implementation. In IPP v4.1 it still have some limitation in functionality, but we continue to extend this sample.
So, my recomendation is to try JPEG-IPP codec if you need maximum speed and you agreed with some limitation, hopefullythey arenot so frequently used features. For example, in IPP v4.1, we do support only 444, 422 and 411 sampling, we do not support scan-interleaved JPEG images, we do not support 255 color components, and so on.
Note, all these limitation is only sample code limitation, you not needed in additional IPP functionality for that and you can extend this sample to support missed features if you need them right now.
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
could you place here the direct link for the results? I think it should be interesting resource for many people..
Regards,
Vladimir

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