Community
cancel
Showing results for 
Search instead for 
Did you mean: 
FredrikHall
Beginner
117 Views

JPEG2000 performance for 16-bit grayscale?

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
115 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
FredrikHall
Beginner
115 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
Thomas_Jensen1
Beginner
115 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.
Sergey_K_Intel
Employee
115 Views

Hi!
Did you try 32-bit or 64-bit? We have seen problems in 64-bit picnic demo.
Regards,
Sergey
FredrikHall
Beginner
115 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
Sergey_K_Intel
Employee
115 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
FredrikHall
Beginner
115 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.
Sergey_K_Intel
Employee
115 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
FredrikHall
Beginner
115 Views

Sergey, thank you for trying, sorry about missing that detail.
Here is a new one (512x512) that hopefully works better!
Sergey_K_Intel
Employee
115 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.
Thomas_Jensen1
Beginner
115 Views

I got errors too, because transfer syntax is Private (1.2.752.24.3.7.7).
Thomas_Jensen1
Beginner
115 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.
Sergey_K_Intel
Employee
115 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.
FredrikHall
Beginner
115 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!
Thomas_Jensen1
Beginner
115 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?
Thomas_Jensen1
Beginner
115 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).

Sergey_K_Intel
Employee
115 Views

Does Intel have any plans to correct the prebuilt 64-bit Picnic?

Yes, it gotta get into 7.0.7 update. Regards.

Thomas_Jensen1
Beginner
115 Views

Sounds good.

Do you know if the malfunctioning Jpeg2000 decoder 16-bit arithmetic bug will be fixed soon?
Sergey_K_Intel
Employee
115 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