The interpretation ( under windows ) of the file jpxproblem.pdf fails with following error messsages: jasper (code 0) jpc_dec_decodepkts failed jasper (code 0) error: cannot decode code stream unable to decode JPX image data. GS call: gswin32c.e -sDEVICE=tiffg4 -o out.tif -dNOPAUSE -dBATCH jpxproblöem.pdf On Linux the GS aborts without error messages. The PDF-file can be viewed and printed with the Acrobat Reader without problems.
Created attachment 5970 [details] jpxproblem.pdf
The file can be rendered by GS 8.64 (and the current HEAD) but it takes about 4GB of memory and a 64-bit system. This is, indeed, an excessive memory allocation but it may be worth to throw some silicon at the problem first.
This file should also be used to determine the memory usage when we switch to OpenJPEG for JPXDecode. Refer to bug: http://bugs.ghostscript.com/show_bug.cgi?id=690543) and this bug is essentially a duplicate of bug: http://bugs.ghostscript.com/show_bug.cgi?id=690230 Note that we should test memory usage using the Luratech JPX decoder. If it uses much less memory, then we want to see if the customer wants to switch. In testing bug 690230, the luratech decoder used even less memory than the OpenJPEG.
Jasper uses 4 bytes per component, i.e. 12 bytes per RGB pixel. It also buffers all decompressed tiles in memory. OpenJPEG has not been maintained recently. Almost all updates go back to 2007-2008. Future development of JPEG 2000 support in Ghostscript needs serious discussion.
Assigning to myself as I own bug 690543 now.
I tried jpxproblem.pdf with openjpeg branch (/branches/jpx_openjpeg/gs) r11006, on Windows XP SP3 + Visual Studio 2008, using command line described in original report. Execution was aborted by null pointer access. At that time, openjpeg was trying to allocate 570MB of memory 3 times, and last one failed. Openjpeg do not check return value from malloc(). Next, I tried same thing with changing application's memory space from 2GB to 3GB (see http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx). This time job finished without an error, I got an output file. I also tried original Jasper version (trunk r11004) with 3GB memory space, it also finished the job and resulted correct output. I'm afraid that switching to openjpeg may not be a solution for this case.
An image in jpxproblem.pdf is a tiled image. (39x59=2184 tiles) Ralph suggested decoding by tiles may be a solution.
Alex please verify this problem with the Luratech build. We have agreed to use Luratech as part of the standard commercial build.
Current gs with Luratech library renders the file correctly and takes 536M of memory. On a rather modest CPU the file takes 30 seconds to render. The file was tested on 64-bit GNU/Linux, release build, GCC 4.5.1 model name : AMD Sempron(tm) Processor LE-1300 stepping : 2 cpu MHz : 1000.000 cache size : 512 KB
The customer should be given the Luratech decoder, the priority lowered to P4, the customer designation removed from the bug report and finally assigned back to Alex. We don't plan any action on this item other than replacing jasper with openjpeg, apparently the openjpeg folks are working on decoding by tiles which should fix this problem.
(In reply to comment #10) > The customer should be given the Luratech decoder, the priority lowered to P4, > the customer designation removed from the bug report and finally assigned back > to Alex. We don't plan any action on this item other than replacing jasper > with openjpeg, apparently the openjpeg folks are working on decoding by tiles > which should fix this problem. Correction, the customer should be directed to the August 2011 release which will have the luratech JPX decoder included. There were several problems in the API which were fixed fairly recently, best to wait for a fully tested release.
I've notified the customer about the August 2011 release via email, so am closing this bug.
*** This bug has been marked as a duplicate of bug 691153 ***