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

[gcode-importer]

Originally reported on Google Code with ID 135

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.

Reported by luca.trisciani on 2012-03-14 16:07:08

---

- _Attachment: [test-12.j2c](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-135/comment-0/test-12.j2c)_

[gcode-importer]

Reported by malaterre on 2012-05-21 14:04:55

• Status changed: Accepted

[gcode-importer]

This issue was updated by revision r1687.

Reported by malaterre on 2012-05-21 14:05:34

[gcode-importer]

issue updated with related tests in r2193

Reported by savmickael on 2012-11-12 16:33:37

[gcode-importer]

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.

Reported by savmickael on 2012-11-13 10:03:53

---

- _Attachment: [patch_opj_issue135.diff](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-135/comment-4/patch_opj_issue135.diff)_

[gcode-importer]

it seems to be related to issue 5 and 62 about allocation of cblk->data

Reported by savmickael on 2012-11-20 10:08:00

[gcode-importer]

Reported by malaterre on 2014-02-25 16:05:17

• Labels added: Milestone-Release2.1

[gcode-importer]

This issue was updated by revision r2486.

Reported by malaterre on 2014-02-26 16:19:41

[gcode-importer]

This issue was updated by revision r2487.

Reported by malaterre on 2014-02-26 16:20:42

[gcode-importer]

Reported by malaterre on 2014-02-27 14:20:25

• Status changed: Started

[gcode-importer]

Issue 259 has been merged into this issue.

Reported by malaterre on 2014-03-07 14:59:13

[gcode-importer]

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!

Reported by malaterre on 2014-03-12 14:56:13

[gcode-importer]

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.000122,0.000122,0.000122,0.000122,0.000122,0.000122,0.000122,0.000122,0.000122

Reported by malaterre on 2014-03-12 15:04:47

[gcode-importer]

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

Reported by szukw000 on 2014-03-12 20:07:06

[gcode-importer]

you need r2709

Reported by malaterre on 2014-03-14 11:07:25

[gcode-importer]

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

Reported by szukw000 on 2014-03-18 12:29:42

[gcode-importer]

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

Reported by malaterre on 2014-03-19 09:25:14

[gcode-importer]

Reported by malaterre on 2014-03-25 10:38:34

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

[gcode-importer]

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

Reported by szukw000 on 2014-04-15 11:02:14

---

- _Attachment: issue135-test-12.j2c-r4.png
_

[szukw000]

I have found that RaspberryPi ( a 32-Bit machine ) does show the KODAK
image of issue135 100% fine with both layers. 'opj_decompress' on the
RaspberryPi decompresses all images 100% fine (except TGA: too dark).

LINUX 32-Bit does show the KODAK image broken. 'opj_decompress' on
LINUX 32-Bit decompresses all images broken.

winfried

[mayeut]

By changing line 1408 of t1.c from

  for (passno = 0; passno < seg->real_num_passes; ++passno) {

to

  for (passno = 0; (passno < seg->real_num_passes) && (bpno_plus_one >= 1); ++passno) {

File seem to decode properly (as well as test_lossless.j2k from the test suite).

I tried this following report from UBSan on CDash: http://my.cdash.org/viewDynamicAnalysisFile.php?id=3209124
I don't know if this is a legitimate correction but thought I'd share what I found.

[szukw000]

@mayeut ,

the change in line 1408 of t1.c was successful:
on LINUX 64-Bit
on Win7 64-Bit
on PPC64

RaspberryPi I could not test because of:

CMake Error at src/lib/openjp2/CMakeLists.txt:88 (target_compile_options):
Unknown CMake command "target_compile_options".

-- Configuring incomplete, errors occurred!

winfried

[mayeut]

@szukw000,

Build error on RPI should be fixed by PR #572 (I guess)

[szukw000]

@mayeut,
unfortunately I can not reproduce that on RaspberryPi. In the meantime I have changed to Debian
Jessie to get the compiler gcc-4.9.2. Jessie has cmake-3.0.2.

winfried

[detonin]

@mayeut could you create a PR with the correction you proposed above ?

[detonin]

This has been fixed by #706
Thanks @mayeut