Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for decoding JPX files #464

Open
gcode-importer opened this issue Dec 24, 2014 · 13 comments
Open

Support for decoding JPX files #464

gcode-importer opened this issue Dec 24, 2014 · 13 comments

Comments

@gcode-importer
Copy link

Originally reported on Google Code with ID 464

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.

Reported by fmichielssen on 2014-12-24 11:08:21

@gcode-importer
Copy link
Author

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.

Reported by malaterre on 2015-01-07 17:40:30

  • Labels added: Priority-Low
  • Labels removed: Priority-Medium

@gcode-importer
Copy link
Author

Reported by mayeut on 2015-01-07 23:20:16

  • Labels added: Type-Enhancement
  • Labels removed: Type-Defect

@gcode-importer
Copy link
Author

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

Reported by szukw000 on 2015-01-10 20:31:43

@gcode-importer
Copy link
Author

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

Reported by szukw000 on 2015-01-13 03:27:23

@gcode-importer
Copy link
Author

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.

Reported by fmichielssen on 2015-01-13 15:22:16

@gcode-importer
Copy link
Author

Frederick wrote:

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

But the bit depth is 1. 

winfried

Reported by szukw000 on 2015-01-14 02:53:49

@gcode-importer
Copy link
Author

Frederick,

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

winfried

Reported by szukw000 on 2015-01-17 02:04:12

@gcode-importer
Copy link
Author

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.

Reported by fmichielssen on 2015-01-17 15:02:03

@gcode-importer
Copy link
Author

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

Reported by szukw000 on 2015-01-17 16:18:19

@gcode-importer
Copy link
Author

Frederick,

could you please send a link to other examples?

winfried

Reported by szukw000 on 2015-02-07 17:21:15

@gcode-importer
Copy link
Author

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

Reported by fmichielssen on 2015-02-10 15:46:14

@gcode-importer
Copy link
Author

Frederick,

which program do you use to ENCODE these images?

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

winfried

Reported by szukw000 on 2015-02-10 17:48:29

@gcode-importer
Copy link
Author

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

Reported by fmichielssen on 2015-02-12 07:25:23

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants