Export to GitHub

openjpeg - issue #464

Support for decoding JPX files


Posted on Dec 24, 2014 by Massive Wombat

What steps will reproduce the problem?

  1. Take a sample JPX file from here: https://share.openanalytics.eu/data/public/76cb6a.php
  2. Decode the file using opj_decompress

What is the expected output? What do you see instead?

The first image decodes correctly, but there is no way to access the other 95 codestreams that are contained in the JPX file.

What version of the product are you using? On what operating system?

Tested using openjpeg release 2.1.0 on Windows 7.

Please provide any additional information below.

While debugging, the following appears to happen: - A JP2 codec is selected to do the decoding - A number of unrecognized boxes are encountered and skipped (I assume these are JPX-specific boxes) - The first JP2 box is found and decoded. This is actually the first of 96 codestreams in the JPX file.

Comment #1

Posted on Jan 7, 2015 by Helpful Giraffe

Just some comments. Technically OpenJPEG only aims as full Part-1 support, some Part-2 extensions have been implemented (eg. MCT), this is why we tolerate some extended Profile in the JP2 header. However lots of Part-2 extensions are still not supported and would lead to invalid output. So downgrading to feature/wishlist.

Comment #2

Posted on Jan 7, 2015 by Quick Lion

(No comment was entered for this change.)

Comment #3

Posted on Jan 10, 2015 by Grumpy Elephant

I would like to know whether the developers are working on implementing JPX.

For a viewer I have written a file that:

  • reads a JPX file
  • collects all JP2C data
  • stores them in files
  • shows the images of the data in a slide show calling each file

No other boxes are taken notice of just now. I would like to know whether I should work further on this code or wait for a fully developed library.

winfried

Comment #4

Posted on Jan 13, 2015 by Grumpy Elephant

The file 'sample2.jpx' contains 5 files.

File 0, 1, 2 have a depth of 8 because the 'ihdr' box has a depth of 8 and the 'SIZ' marker has a depth of 8. The images have a light color.

File 3 has a depth of 1 because the 'ihdr' box and the 'SIZ' marker has such depth. This file is very dark.

File 4 should have a depth of 1 because the 'ihdr' box has such depth. But the 'SIZ' marker has a depth of 8. This file is simply black.

And the creating application Kakadu is headstrong, perhaps trash.

Reader Requirements Box

ML Values: 1, 2, 4 and 8 SF Values:

sample1.jpx:

com R[1](General use (ISO 8859-1 (latin-1) values)) T(Kakadu-v6.1.1)

rreq ml(3) fuam(65280) dcm(255) nsf(12) [ 0]sf( 5) Deprecated [ 1]sf(46) Deprecated [ 2]sf( 2) Contains multiple composition layers: only one found [ 3]sf(17) [ 4]sf(26) Animated ...: no [ 5]sf(28) Animated ...: no [ 6]sf(30) Animated ...: no [ 7]sf(33) [ 8]sf( 1) Deprecated [ 9]sf( 8) Deprecated [10]sf(12) Deprecated [11]sf(20) Deprecated nvf(0)

sample2.jpx:

com R[1](General use (ISO 8859-1 (latin-1) values)) T(Kakadu-v7.2.2)

rreq ml(2) fuam(255) dcm(0) nsf(8) [ 0]sf( 5) [ 1]sf(46) Deprecated [ 2]sf(18) Deprecated [ 3]sf( 1) Deprecated [ 4]sf( 8) Deprecated [ 5]sf(12) Deprecated [ 6]sf(31) Deprecated [ 7]sf(20) Deprecated

The 'Deprecated' values are from 2007:

ISO/IEC 15444-2:2004/Cor.4:2007 (E)

winfried

Comment #5

Posted on Jan 13, 2015 by Massive Wombat

I currently have no intention of adding JPX support to the library, since I lack the expertise to do so.

Regarding sample2.jpx: File 3 is a binary label image; in our application it is rendered with a user-selected color. You are right about File 4: it is an 8-bit placeholder filled with zero-value pixels, and not really useful as an example.

Comment #6

Posted on Jan 14, 2015 by Grumpy Elephant

Frederick wrote:

in our application it is rendered with a user-selected color

But the bit depth is 1.

winfried

Comment #7

Posted on Jan 17, 2015 by Grumpy Elephant

Frederick,

which system do you use? Do you have fltk-1.3 installed (from http://www.fltk.org )

winfried

Comment #8

Posted on Jan 17, 2015 by Massive Wombat

Hi Winfried,

We don't use fltk. Currently, we use Kakadu & its Java bindings to do the following: - Decode pixels - Blend & color pixels according to user preferences (so not using a fixed colorspace) - Display image on screen in a Java application based on Eclipse RCP

The 1bit images are usually rendered on top of other images, as follows: - Value zero is ignored (transparent) - Value one replaces the underlying color with a user-selected color.

In the case of sample2.jpx: - files 0,1,2 would be rendered as an RGB image (representing a rat brain slice) - file 3 would be rendered on top of it as a set of cyan outlines (representing amyloid plaques in the brain).

I'll try to get some better examples and screenshots next week.

Comment #9

Posted on Jan 17, 2015 by Grumpy Elephant

So you are satisfied.

I asked for your system and FLTK because I use LINUX/Win7 and FLTK. The JPX code I am writing is for an FLTK application.

winfried

Comment #10

Posted on Feb 7, 2015 by Grumpy Elephant

Frederick,

could you please send a link to other examples?

winfried

Comment #11

Posted on Feb 10, 2015 by Massive Wombat

Hi Winfried,

Sorry, forgot about this. Here are some additional examples: https://dl.dropboxusercontent.com/u/84221478/readme.txt

Note that we use JPX simply as a container format for codestreams; we don't use special JPX features such as compositing layers. In fact, we just refactored our application so that it accepts codestreams from a ZIP file as well, giving us more freedom in choice of codec.

Regards, Frederick

Comment #12

Posted on Feb 10, 2015 by Grumpy Elephant

Frederick,

which program do you use to ENCODE these images?

Thank you for the other example files. I have downloaded them.

winfried

Comment #13

Posted on Feb 12, 2015 by Massive Wombat

Those JPX files were created using Kakadu 7.4.0 on Win7 x64.

Status: New

Labels:
Type-Enhancement Priority-Low