What steps will reproduce the problem?
- Take a sample JPX file from here: https://share.openanalytics.eu/data/public/76cb6a.php
- 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 GiraffeJust 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 ElephantI 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 ElephantThe 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 WombatI 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 ElephantFrederick 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 ElephantFrederick,
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 WombatHi 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 ElephantSo 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 ElephantFrederick,
could you please send a link to other examples?
winfried
Comment #11
Posted on Feb 10, 2015 by Massive WombatHi 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 ElephantFrederick,
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 WombatThose JPX files were created using Kakadu 7.4.0 on Win7 x64.
Status: New
Labels:
Type-Enhancement
Priority-Low