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?
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 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
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.
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.
This DICOM version format is not supported by UIC DICOM codec. Here is Transfer Syntax UID=1.2.7184.108.40.206.7 (private syntax of Philips Medical Systems), which is not known by UIC decoder. It processes 1.2.840.* UIDs only.
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.
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).