Memory usage when decoding JPEG2K

[kamil_zukowski]

Hello,

I use UIC for decoding JPEG2K (according to example uic_transcoder_con).

Everything works fine, however I noticed the "ReadImageJPEG2000" function allocates a lot of memory - in example jp2 image with size more less 6,5MB and resolution 4750x3170 needs about 400MB of memory for decoding. Sometimes (not enough available memory) it causes serious problems.

Is there any way to reduce this memory consumption? Any kind of parameters I can set? Do I do it wrong? Or maybe it is normal, decoding algoritms require that amount of memory, and there is nothing I can do?

Greetings,
Kamil Zukowski

[Thomas_Jensen1]

If possible, I'd like to debug with your test file.

[kamil_zukowski]

If you mean this 6,5MB jp2 image I can upload it tomorrow morning.

Added:
I attached this test jp2 image file.

Also I show you memory usage graph below.



I tried few popular image viewers as well and their memory consumption is about 60-250 MB.

[Vladimir_Dudnik]

Hello,

JPEG2000compression algorithmis based on wavelet transform, which require whole image size intermediate buffer to keep wavelet coefficients in our implementation. The JPEG2000 codec implementations differs in memory requirements depending on whetherthey support progressive image reading from stream orsimpleuse file seeking to access data in random order. Implementation in IPP UIC rely on progressive reading from stream and sorequire more memory on intermediate steps.

Regards,
Vladimir

[Thomas_Jensen1]

I tested with my custom DLL with a jpeg2000 decoder using IPP 6.1.5.
I also tested with a sample app from LeadTools 16.5, and again with ACDsee Pro 3.

My testpc: AMD Phenom 4X at 3GHz, Windows 7, 32-bit.

IPP custom DLL: 1.7sec decoding time (using 4 cores), 70MByte to 600MByte memory usage spike.
LeadTools: 5sec decoding time (single-threaded), 16MByte to 28MByte memory usage spike.
ACDSee: 1sec decoding time (single-threaded), 55MByte to 65MByte memory usage spike.

It is clear that IPP is a memory hog, in comparison to other jpeg2000 decoders.

[kamil_zukowski]

Indeed, results of my tests are similar.

So the conclusion is I can not do anything to decrease memory usage with UIC implementation, can I?

Alternatives:
- own implementation using IPP,
- another JP2K codec,
- using tricks (creating new system process just for decoding?)
I would like to hear other solutions if anyone knows.

Anyway thank you both for responses.

Regards,
Kamil Zukowski

[Thomas_Jensen1]

I just tested with IPP 7 beta, Picnic.exe, 32-bit, on a Phenom X4 3GHz.

Decode time of your test file = 3.1sec. It seems it is single-threaded (Process Explorer shows 25% CPU peak). Does anybody know if it aught to be multi-threaded?

[Thomas_Jensen1]

The real question is; is this IPP memory problem important?

The answer can only be:

- If your end-user computer has little RAM (<1GByte), then the 600MByte peak will flush all other process memory out to swap file, slowing your APP, and the other processes to a crawl, until the swap file (on the slow HD) has been read back into RAM. This shurely would cause a fast CPU to be considered a slow CPU.

- If your computer has plenty of RAM (>2GByte), then the 600MByte peak will not disturb anything.

In my opinion, Intel should look into the mirror, and ask themselves, do we want to supply/sell IPP in light of what those other suppliers sell, considering that we want to be the best, performance-wise?

I personally think, wow! low-cost Intel IPP Jpeg2000 decoder software, and high-performance image filters, all roalty-free!

The other end of the coin is that it seems Intel will make IPP incompatible with legacy processors (IPP 7).