JPEG2000 performance for 16-bit grayscale?

[FredrikHall]

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?

[Ying_H_Intel]

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 Executables

download

download

download

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]

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]

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]

Hi!

Did you try 32-bit or 64-bit? We have seen problems in 64-bit picnic demo.

Regards,

Sergey

[FredrikHall]

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]

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]

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]

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]

Sergey, thank you for trying, sorry about missing that detail.
Here is a new one (512x512) that hopefully works better!

[Sergey_K_Intel]

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]

I got errors too, because transfer syntax is Private (1.2.752.24.3.7.7).

[Thomas_Jensen1]

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]

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]

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]

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]

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]

Quoting Thomas Jensen

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

Yes, it gotta get into 7.0.7 update. Regards.

[Thomas_Jensen1]

Sounds good.

Do you know if the malfunctioning Jpeg2000 decoder 16-bit arithmetic bug will be fixed soon?

[Sergey_K_Intel]

Quoting Thomas Jensen

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

[Thomas_Jensen1]

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).