Bug 691122 - failure with JPX image data in PDF
failure with JPX image data in PDF
Status: NOTIFIED DUPLICATE of bug 691153
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter
8.64
PC Windows XP
: P2 normal
Assigned To: Marcos H. Woehrmann
Bug traffic
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-19 03:08 PST by artifex
Modified: 2012-04-16 19:15 PDT (History)
4 users (show)

See Also:
Customer: 870
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description artifex 2010-02-19 03:08:38 PST
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.
Comment 1 artifex 2010-02-19 03:10:01 PST
Created attachment 5970 [details]
jpxproblem.pdf
Comment 2 Alex Cherepanov 2010-02-19 18:17:22 PST
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.
Comment 3 Ray Johnston 2010-02-20 11:03:23 PST
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.
Comment 4 Alex Cherepanov 2010-02-21 10:33:06 PST
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.
Comment 5 Masaki Ushizaka 2010-02-21 18:38:19 PST
Assigning to myself as I own bug 690543 now.
Comment 6 Masaki Ushizaka 2010-04-04 12:21:20 PDT
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.
Comment 7 Masaki Ushizaka 2010-04-08 08:19:43 PDT
An image in jpxproblem.pdf is a tiled image.
(39x59=2184 tiles)
Ralph suggested decoding by tiles may be a solution.
Comment 8 Henry Stiles 2011-04-13 23:25:22 PDT
Alex please verify this problem with the Luratech build.  We have agreed to use Luratech as part of the standard commercial build.
Comment 9 Alex Cherepanov 2011-05-03 23:14:31 PDT
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
Comment 10 Henry Stiles 2011-05-04 03:05:53 PDT
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.
Comment 11 Henry Stiles 2011-06-10 16:15:14 PDT
(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.
Comment 12 Marcos H. Woehrmann 2011-08-16 15:16:58 PDT
I've notified the customer about the August 2011 release via email, so am closing this bug.
Comment 13 Marcos H. Woehrmann 2011-08-16 15:25:48 PDT

*** This bug has been marked as a duplicate of bug 691153 ***