search

troosh / openjpeg

Automatically exported from code.google.com/p/openjpeg
Other
0 stars 0 forks source link

Problem with second layer of a 2 layer coded LRCP (with precincts) #135

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. j2k_to_image -l 2 -i test-12.j2c -o test-12.tif
2. (see attached test-12.j2c)
3.

What is the expected output? What do you see instead?
The program does not complain, but the output is
wrongly decoded, with a lot of garbage. 

What version of the product are you using? On what operating system?
openjpeg 1.5.0 on fedora 16 (3.2.9-2.fc16.x86_64)

Please provide any additional information below.

Decoding only the first layer does work correctly. 
Decondig with kakadu works correctly for both layers.
I think the codestream is legal, but I am not 100% sure.

Original issue reported on code.google.com by luca.tri...@gmail.com on 14 Mar 2012 at 4:07

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by mathieu.malaterre on 21 May 2012 at 2:04

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r1687.

Original comment by mathieu.malaterre on 21 May 2012 at 2:05

GoogleCodeExporter commented 9 years ago 
issue updated with related tests in r2193

Original comment by savmick...@gmail.com on 12 Nov 2012 at 4:33

GoogleCodeExporter commented 9 years ago 
This file generate problem also with the trunk with the following commands:
opj_decompress -i kodak_2layers_lrcp.j2c -o /tmp/kodak_2layers_lrcp.j2c.pgx
opj_decompress -i kodak_2layers_lrcp.j2c -o /tmp/kodak_2layers_lrcp.j2c.pgx -l 2
opj_decompress fail

To solve the first I propose the attached patch but I am not sure
After apply this patch the second command generated an output quite weird.

Original comment by savmick...@gmail.com on 13 Nov 2012 at 10:03

Attachments:

GoogleCodeExporter commented 9 years ago 
it seems to be related to issue 5 and 62 about allocation of cblk->data

Original comment by savmick...@gmail.com on 20 Nov 2012 at 10:08

GoogleCodeExporter commented 9 years ago

Original comment by mathieu.malaterre on 25 Feb 2014 at 4:05

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2486.

Original comment by mathieu.malaterre on 26 Feb 2014 at 4:19

GoogleCodeExporter commented 9 years ago 
This issue was updated by revision r2487.

Original comment by mathieu.malaterre on 26 Feb 2014 at 4:20

GoogleCodeExporter commented 9 years ago

Original comment by mathieu.malaterre on 27 Feb 2014 at 2:20

GoogleCodeExporter commented 9 years ago 
Issue 259 has been merged into this issue.

Original comment by mathieu.malaterre on 7 Mar 2014 at 2:59

GoogleCodeExporter commented 9 years ago 
Here is one odd discovery:

$ kdu_transcode -i data/input/nonregression/issue135.j2k -o issue135.trans.j2k
$ ./bin/opj_decompress -i issue135.trans.j2k -o issue135.trans.j2k.ppm
read: segment too long (6182) with max (35872) for codeblock 0 (p=19, b=2, r=5, 
c=1)
[ERROR] Failed to decode.
[ERROR] Failed to decode tile 1/1
ERROR -> opj_decompress: failed to decode image!

Original comment by mathieu.malaterre on 12 Mar 2014 at 2:56

Attachments:

GoogleCodeExporter commented 9 years ago 
With a similar looking image, opj_decompress seems to be doing fine:

$ kdu_expand -i data/input/nonregression/issue135.j2k -o r.tif,g.tif,b.tif
$ kdu_compress -precise -no_info -i r.tif,g.tif,b.tif -o issue135.kdu_comp.j2k 
-record test.txt Clayers=2 Cuse_precincts=yes 
"Cprecincts={256,256},{256,256},{256,256},{256,256},{256,256},{128,128}" 
"Cblk={32,32}" -no_weights Qguard=2 
Qabs_steps=0.000122,0.000244,0.000244,0.000244,0.000244,0.000244,0.000244,0.0001
22,0.000122,0.000122,0.000122,0.000122,0.000122,0.000122,0.000122,0.000122

Original comment by mathieu.malaterre on 12 Mar 2014 at 3:04

GoogleCodeExporter commented 9 years ago 
KDU733_Demo_Apps_for_Linux-x86-64_140118
========================================

kdu_transcode -i data/input/nonregression/issue135.j2k -o issue135.trans.j2k

Codestream #1/1
---------------
    Output contains 2 quality layers
    Transferred 9768 code-blocks.

    Read 1 tile-part(s) from a total of 1 tile(s).
    Total bytes read = 2,359,485 = 5.923354 bits/pel.

    Wrote 1 tile-part(s) in a total of 1 tile(s).
    Total bytes written = 2,359,826 = 5.924210 bits/pel.
    All header (marker segment) bytes written = 143
    Layer bit-rates (possibly inexact if tiles are divided across tile-parts):
        4.758556, 5.924210

openjpeg-trunk-r2694-1:
=======================

BUILD/bin/opj_decompress -i issue135.trans.j2k -o issue135.trans.j2k.ppm

[INFO] Start to read j2k main header (0).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Header of tile 0 / 0 has been read.
[ERROR] Failed to decode.
[ERROR] Failed to decode tile 1/1
ERROR -> opj_decompress: failed to decode image!

'segment too long' is missing.

winfried

Original comment by szukw...@arcor.de on 12 Mar 2014 at 8:07

GoogleCodeExporter commented 9 years ago 
you need r2709

Original comment by mathieu.malaterre on 14 Mar 2014 at 11:07

GoogleCodeExporter commented 9 years ago 
The image 'issue135-test-12.j2c' remains to be broken.

I have made a test. In 'opj_j2k_read_cod()' of 'j2k.c', I changed the value
of layers from 2 to 1.

The resulting image is attached.

winfried

Original comment by szukw...@arcor.de on 18 Mar 2014 at 12:29

Attachments:

GoogleCodeExporter commented 9 years ago 
As discovered by Winfried, the following leads to a much better decompression:

$ ./bin/opj_decompress -l 1 -i data/input/nonregression/issue135.j2k -o 
one_level.ppm

Original comment by mathieu.malaterre on 19 Mar 2014 at 9:25

GoogleCodeExporter commented 9 years ago

Original comment by mathieu.malaterre on 25 Mar 2014 at 10:38

GoogleCodeExporter commented 9 years ago 
I have installed openjpeg-2.x-trunk-r2833 on a G5 machine (debian wheezy PPC64).
I have then decompressed 'test-12.j2c' on that machine.

And found that the full image does only have two broken planes: one in the 
hair and one on the left side.

Most interesting: the reduced images on that machine are without failure.

The attached image has a reduction of 4.

The code for BE in 'cio.c' naturally has been corrected as proposed
elsewhere.

winfried

Original comment by szukw...@arcor.de on 15 Apr 2014 at 11:02

Attachments: