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

JPEG2000 performance for 16-bit grayscale?

FredrikHall
Beginner
973 Views
I am currently using a competing SDK/toolkit, but would be interested in switching to IPP if there is a noticable performance difference.My main usage is for medical images, commonly 16-bit per pixel and grayscale.

What kind of decompression performance can I expect for a 512x512 image, in milliseconds? Of course still will depend on the CPU used, but any example would be important for me. I can then compare that with my current benchmark and do a rough comparison.

Would it be possible to reach say 5ms for a 512x512 16-bit grayscale image on a modern i7 CPU?
0 Kudos
20 Replies
Ying_H_Intel
Employee
961 Views
Hi Fredrikhall,

I may recommend you to try UICexample with your image and get the performanceresult quickly.

As UIC example provide exectuable fileat Code Samples for Intel IPP Library 7.0*
UIC Executablesdownloaddownloaddownload

and please take a look readme_demo.htm and get the decompression performance in bottom bar.

Sincerely
Ying H.
some latest performance benchmark in http://software.intel.com/en-us/articles/intel-ipp/#details
0 Kudos
FredrikHall
Beginner
961 Views
Thank for your input! However when trying to run the UIC executable the programs seems to crash whever I try to do something (selecting Load file, Options, etc). The programs starts, but cannot be used.
Any suggestions? I am more than happy to send some sample images, if this is easier than helping me get Picnic up and running...This is one of the many Windows error logs:
Problem signature:
Problem Event Name: APPCRASH
Application Name: picnic.exe
Application Version: 0.0.0.0
Application Timestamp: 4ed60bb6
Fault Module Name: StackHash_133e
Fault Module Version: 6.1.7600.16695
Fault Module Timestamp: 4cc7b325
Exception Code: c0000374
Exception Offset: 00000000000c6ab2
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1053
Additional Information 1: 133e
Additional Information 2: 133ebc4a2ad829ccbb4b4fe83ea2ecca
Additional Information 3: 58b4
Additional Information 4: 58b4dee344df429ee41f620386ad792d
Problem signature: Problem Event Name: APPCRASH Application Name: picnic.exe Application Version: 0.0.0.0 Application Timestamp: 4ed60bb6 Fault Module Name: StackHash_133e Fault Module Version: 6.1.7600.16695 Fault Module Timestamp: 4cc7b325 Exception Code: c0000374 Exception Offset: 00000000000c6ab2 OS Version: 6.1.7600.2.0.0.256.48 Locale ID: 1053 Additional Information 1: 133e Additional Information 2: 133ebc4a2ad829ccbb4b4fe83ea2ecca Additional Information 3: 58b4 Additional Information 4: 58b4dee344df429ee41f620386ad792d
0 Kudos
Thomas_Jensen1
Beginner
961 Views
Well Picnic.exe requires all IPP dll files I guess.. do yo have them?

I you can enclose one of your 16bit images, I can test the decompression time.
0 Kudos
Sergey_K_Intel
Employee
961 Views
Hi!
Did you try 32-bit or 64-bit? We have seen problems in 64-bit picnic demo.
Regards,
Sergey
0 Kudos
FredrikHall
Beginner
961 Views
Yes, it was the 64-bit version. When trying the 32-bit one it fails as well, but perhaps that is due to having 64-bit IPP? Or would the installer provide both binaries?
Regards,
Fredrik
0 Kudos
Sergey_K_Intel
Employee
961 Views
Hi Fredrik,
If your application fails with messagebox "The application was unable to start correctly (0xc000007b)...", this is because of mix of 32-bit application and 64-bit DLLs. You need to set your PATH env. variable so, that 32-bit DLL folders come first. It can be done either manually, or calling proper xxVARS.bat command files with proper arguments (often, "xxVARS.bat ia32"). For IPP it is "ippvars.bat", for TBB it is "tbbvars.bat", for compiler libs it is "compilervars.bat/iclvars.bat". Check everything around your current IPPROOT dir. E.g. "cd %IPPROOT%".
PICNIC.exe depends not only on UIC*.dll files, but also on TBB dlls, LIBIOMP5MD.dll, LIBMMD.dll (probably, that's all). These DLLs also come in two versions (ia32 and intel64). So, for all these DLLs you'll need 32-bit versions (that is, appropriate 32-bit-variant folders must come first in PATH variable).
Also, check your product documentation on how to setup environment.
Regards,
Sergey
0 Kudos
FredrikHall
Beginner
961 Views
Thomas, an example file can be found here. It is not the 512x512 case, but it would at least give a hint to IPP performance compared to other SDKs. Any input on the time needed to decompress (and the CPU used) would be most welcome! Sergey, thank you for the suggestions! I will check my env.var and see if I can iron out the 32 vs 64-bit differences.
0 Kudos
Sergey_K_Intel
Employee
961 Views
Fredrik,
This DICOM version format is not supported by UIC DICOM codec. Here is Transfer Syntax UID=1.2.752.24.3.7.7 (private syntax of Philips Medical Systems), which is not known by UIC decoder. It processes 1.2.840.* UIDs only.
Regards,
Sergey
0 Kudos
FredrikHall
Beginner
961 Views
Sergey, thank you for trying, sorry about missing that detail.
Here is a new one (512x512) that hopefully works better!
0 Kudos
Sergey_K_Intel
Employee
961 Views
Fredrik, sad news(( On my Core2 2.4GHz i got ~70 msec. Doubt if i7 can be 10x faster to reach your goal of 5 msec.
0 Kudos
Thomas_Jensen1
Beginner
961 Views
I got errors too, because transfer syntax is Private (1.2.752.24.3.7.7).
0 Kudos
Thomas_Jensen1
Beginner
961 Views
AMD Phenum II X4 980 (Deneb) at 3,8GHz, I get 48msec (using SSE2 library) using Picnic on Windows 7 32-bit.

XEON E5410 4-core (Harpertown) at 2.33GHz, I get 69msec using Picnic 32-bit on Server 2008 64-bit.

Picnic 64-bit crashes when clicking the open file button.

Pinic is from samples 7.0.6.060.
0 Kudos
Sergey_K_Intel
Employee
961 Views
Thomas, picnic-64 (prebuilt image) is not workable due to improper 64-bit version of Qt library used. If you have your own Qt 64-bit library (4.7.1 can be built from sources), you can rebuild picnic following readmes.
0 Kudos
FredrikHall
Beginner
961 Views
Thanks for testing on some different machines - that kind of rough feeling for expected performance is exactly what I was hoping for!

With our current library (Kakadu) I get 30-50ms on my mobile Sandy Bridge dual core.
The bottom line is that IPP would not give a substantial performance improvement, if any.

Perhaps I was hoping that Intels low-level magic could work wonders, but I guess the codec is simply too computationally expensive.

Again, thanks for the input!
0 Kudos
Thomas_Jensen1
Beginner
961 Views
I have not yet built 64-bit samples using my Intel C++ 64-bit compiler, and I remember QT was very complex to set up, when I once recompiled Picnic 32-bit, although I did succeed.

Does Intel have any plans to correct the prebuilt 64-bit Picnic?
0 Kudos
Thomas_Jensen1
Beginner
961 Views
The Intel IPP Jpeg2000 codec has an option to use an internal arithmetic mode of 16-bit or 32-bit.
Picnic is always using the Jpeg2000 32-bit arithmetic mode, although its UI has an option to select 16-bit arithmetic mode, but that is ignored.

When decoding an Jpeg2000 encoded 16-bit image in 16-bit arithmetic mode, you cannot have more than 14 bits precision, that is, your pixels should have all values 0..16383.

Using 16-bit arithmetic mode is significantly faster, and uses significantly less decoder memory.

There is just one problem; this 16-bit arithmetic mode does not work at the moment; it decodes incorrectly, at least when decoding 8-bit pixel images. I did not test with 16-bit pixel images yet, it could be that it works fine (as long as the values are 0..16383).

0 Kudos
Sergey_K_Intel
Employee
961 Views
Does Intel have any plans to correct the prebuilt 64-bit Picnic?

Yes, it gotta get into 7.0.7 update. Regards.

0 Kudos
Thomas_Jensen1
Beginner
961 Views
Sounds good.

Do you know if the malfunctioning Jpeg2000 decoder 16-bit arithmetic bug will be fixed soon?
0 Kudos
Sergey_K_Intel
Employee
961 Views
Do you know if the malfunctioning Jpeg2000 decoder 16-bit arithmetic bug will be fixed soon?

I will check what's wrong. It may happen, that the fix (if any) will be in the next release too.

Regards,

Sergey

0 Kudos
Thomas_Jensen1
Beginner
822 Views
I also put this particular problem into Premier Suppoer at # 650005 two months ago.

To me, it is outmost important that Intel IPP has the highest performance possible.
So, when using 8bit per channel (color and 8bpp grayscale), it is logical to want to use IPP Jpeg2000 arithmetic mode 16-bit, to make encoding and decoding as fast as can be (with IPP).
0 Kudos
Reply