Support for decoding JPX files

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by fmichiel...@gmail.com on 24 Dec 2014 at 11:08

[GoogleCodeExporter]

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.

Original comment by mathieu.malaterre on 7 Jan 2015 at 5:40

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by m.darb...@gmail.com on 7 Jan 2015 at 11:20

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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

Original comment by szukw...@arcor.de on 10 Jan 2015 at 8:31

[GoogleCodeExporter]

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

Original comment by szukw...@arcor.de on 13 Jan 2015 at 3:27

[GoogleCodeExporter]

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.

Original comment by fmichiel...@gmail.com on 13 Jan 2015 at 3:22

[GoogleCodeExporter]

Frederick wrote:

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

But the bit depth is 1. 

winfried

Original comment by szukw...@arcor.de on 14 Jan 2015 at 2:53

[GoogleCodeExporter]

Frederick,

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

winfried

Original comment by szukw...@arcor.de on 17 Jan 2015 at 2:04

[GoogleCodeExporter]

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.

Original comment by fmichiel...@gmail.com on 17 Jan 2015 at 3:02

[GoogleCodeExporter]

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

Original comment by szukw...@arcor.de on 17 Jan 2015 at 4:18

[GoogleCodeExporter]

Frederick,

could you please send a link to other examples?

winfried

Original comment by szukw...@arcor.de on 7 Feb 2015 at 5:21

[GoogleCodeExporter]

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

Original comment by fmichiel...@gmail.com on 10 Feb 2015 at 3:46

[GoogleCodeExporter]

Frederick,

which program do you use to ENCODE these images?

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

winfried

Original comment by szukw...@arcor.de on 10 Feb 2015 at 5:48

[GoogleCodeExporter]

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

Original comment by fmichiel...@gmail.com on 12 Feb 2015 at 7:25