dump issue with one conformance file: file9.jp2

[gcode-importer]

Originally reported on Google Code with ID 96

What steps will reproduce the problem?
1. j2k_dump -i file9.jp2 -o dump-file9.jp2-1.txt
2. j2k_dump -i file9.jp2 -o dump-file9.jp2-2.txt
3. compare the output files

Dump is correctly done but output is variable. More precisely stepsize values are different.

Reported by savmickael on 2011-10-07 13:45:34

[gcode-importer]

valgrind is going nuts on this file:


[INFO] tile 1 of 1
[INFO] - tiers-1 took 7.724482 s
[INFO] - dwt took 0.256016 s
[INFO] - tile decoded in 8.204513 s
==22574== Invalid read of size 4
==22574==    at 0x4042D8: j2k_dump_cp (j2k_dump.c:642)
==22574==    by 0x403C91: main (j2k_dump.c:517)
==22574==  Address 0x5f561f4 is 0 bytes after a block of size 1,076 alloc'd
==22574==    at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==22574==    by 0x402ABA1: j2k_read_siz (j2k.c:602)
==22574==    by 0x402E5B6: j2k_decode (j2k.c:1919)
==22574==    by 0x4031CBE: opj_jp2_decode (jp2.c:749)
==22574==    by 0x4034DCF: opj_decode_with_info (openjpeg.c:168)
==22574==    by 0x4034D41: opj_decode (openjpeg.c:157)
==22574==    by 0x403BC9: main (j2k_dump.c:500)

Reported by malaterre on 2012-05-29 16:35:21

[gcode-importer]

Breakpoint 3, j2k_read_siz (j2k=0x418300) at /home/mathieu/Projects/OpenJPEG/svn/branches/openjpeg-1.5/libopenjpeg/j2k.c:602
602     j2k->default_tcp->tccps = (opj_tccp_t*) opj_calloc(image->numcomps, sizeof(opj_tccp_t));
(gdb) p image->numcomps
$3 = 1

and then:


Breakpoint 4, j2k_dump_cp (fd=0x418010, img=0x41a730, cp=0x419970) at /home/mathieu/Projects/OpenJPEG/svn/branches/openjpeg-1.5/applications/codec/j2k_dump.c:642
642             fprintf(fd, "      csty=%x\n", tccp->csty);

(gdb) p img->numcomps
$4 = 3

CQFD

Reported by malaterre on 2012-05-29 16:59:44

[gcode-importer]

Reported by malaterre on 2014-02-25 15:27:49

• Labels added: Priority-High, Milestone-Release2.1
• Labels removed: Priority-Medium, 1.5

[gcode-importer]

I can no longer reproduce this behavior, this has been fixed since then. closing.

Reported by malaterre on 2014-02-27 10:16:36

• Status changed: Fixed

[gcode-importer]

Reported by detonin on 2014-03-24 15:57:45

• Labels added: Conformance

[detonin]

Bug still present
dump output is unstable.

226/1207 Testing: NR-file9.jp2-compare_dump2base
226/1207 Test: NR-file9.jp2-compare_dump2base
Command: "/Users/antonin/dev/opj/github/openjpeg15-build/bin/compare_dump_files" "-b" "/Users/antonin/dev/opj/github/openjpeg-data/baseline/nonregression/opj_file9.txt" "-t" "/Users/antonin/dev/opj/github/openjpeg15-build/tests/conformance/Temporary/file9.jp2.txt"
Directory: /Users/antonin/dev/opj/github/openjpeg15-build/tests/conformance
"NR-file9.jp2-compare_dump2base" start time: Sep 17 10:01 CEST
Output:
----------------------------------------------------------
<      numgbits=0> vs. <      numgbits=147865536>
******Parameters********* 
 base_filename = /Users/antonin/dev/opj/github/openjpeg-data/baseline/nonregression/opj_file9.txt
 test_filename = /Users/antonin/dev/opj/github/openjpeg15-build/tests/conformance/Temporary/file9.jp2.txt
************************* 
Try to open: /Users/antonin/dev/opj/github/openjpeg-data/baseline/nonregression/opj_file9.txt for reading ... Ok.
Try to open: /Users/antonin/dev/opj/github/openjpeg15-build/tests/conformance/Temporary/file9.jp2.txt for reading ... Ok.
<end of output>
Test time =   0.00 sec
----------------------------------------------------------
Test Failed.
"NR-file9.jp2-compare_dump2base" end time: Sep 17 10:01 CEST
"NR-file9.jp2-compare_dump2base" time elapsed: 00:00:00
----------------------------------------------------------

[detonin]

same problem with issue104_jpxstream.jp2

[detonin]

j2k codestream in file9.jp2 has one component but decoder output is 3 components thanks to a component mapping box and a palette box in jp2 structure.
So decoded file shall be 3 components but dumped file shall refer to only one component (j2k_dump only analyzes the codestream, not the jp2 file format).
Same problem with issue104_jpxstream.jp2

[detonin]

fixed by 32b04ad