image rejected for padding(?)

[gcode-importer]

Originally reported on Google Code with ID 226

The attached file contains for whatever reason the two byte sequence 0x8080 right before
the terminating EOC marker which causes openjpeg to reject the otherwise intact image.
LuraTech and whatever Adobe uses accept the image, though, so rejection isn't expected.

Reported by zeniko on 2013-06-14 19:47:03

---

- _Attachment: [testcase 2325.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-226/comment-0/testcase 2325.jp2)_

[gcode-importer]

testcase-2325.jp2 is a J2K image. The TRUNK does return the
correct decod_format (J2K), the BRANCH does not.

TRACE from the TRUNK:

/sources/LIB/OPENJPEG/TRUNK/openjpeg-trunk-r2343-5/src/lib/openjp2/j2k.c:7284:
        TRACE l_current_marker(0x8080) byte_left(2)

Added patch code in line 7297. Test in line 7293 could perhaps be:

if(opj_stream_get_number_byte_left(p_stream) <= 2) {
    p_j2k->m_specific_param.m_decoder.m_state = J2K_STATE_NEOC;
    return OPJ_TRUE;
}

The patch for the BRANCH tests for

  if(cio_numbytesleft(cio) > 2) ERROR; else ACCEPT;


Perhaps one should follow the comment in the BRANCH:

  not end of file reached and no EOC

  if(opj_stream_get_number_byte_left(p_stream) != 0) ACCEPT;

  if(if(cio_numbytesleft(cio) != 0) ACCEPT;

winfried

Reported by szukw000 on 2013-06-29 20:12:00

---

- _Attachment: [openjpeg-trunk-r2343-5-jk2.c.dif.gz](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-226/comment-1/openjpeg-trunk-r2343-5-jk2.c.dif.gz)_ - _Attachment: [openjpeg-branch15-r2343-3.dif.gz](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-226/comment-1/openjpeg-branch15-r2343-3.dif.gz)_

[gcode-importer]

There exists a difference in the resulting output image: the BRANCH image
has a red background on which a white page is placed.

winfried

Reported by szukw000 on 2013-06-30 12:06:33

[gcode-importer]

The 'testcase' file has a trailing '0x8080' marker; the 'fonzy' file has
one or more trailing '0x0000' marker(s).

openjpeg-branch-2343
===================
j2k.c:

j2k_decode()
{
...
   if (id >> 8 != 0xff)
  {
   if(cio_numbytesleft(cio) != 0)/* not end of file reached and no EOC */
 {
   opj_event_msg(cinfo, EVT_ERROR, "I:%.8x: expected a marker instead of %x\n", cio_tell(cio)
- 2, id);
   continue; /* skip this invalid marker */
 }
   opj_event_msg(cinfo, EVT_WARNING, "II:%.8x: expected a marker instead of %x\n",
cio_tell(cio) - 2, id);
   j2k->state = J2K_STATE_NEOC;
   break;
  }
...
}

EXAMPLE 1
=========
./j2k_to_image -i testcase-2325.jp2 -o testcase.png

===========================================
The extension of this file is incorrect.
FOUND .jp2. SHOULD BE .j2k or .jpc or .j2c
===========================================

[ERROR] I:00003f79: expected a marker instead of 8080
[INFO] tile 1 of 1
[INFO] - tiers-1 took 0.030000 s
[INFO] - dwt took 0.081000 s
[INFO] - tile decoded in 0.134000 s
Successfully generated Outfile testcase.png


EXAMPLE 2
=========
./j2k_to_image -i fonzy-file409752.jp2 -o fonzy.png

[WARNING] II:00001f1e: expected a marker instead of 0
[INFO] tile 1 of 1
[INFO] - tiers-1 took 0.005000 s
[INFO] - dwt took 0.002000 s
[INFO] - tile decoded in 0.009000 s
Successfully generated Outfile fonzy.png


openjpeg-trunk-2343
===================
j2k.c:

opj_j2k_decode_tile()
{
(...)
   else if (l_current_marker != J2K_MS_SOT)
  {
   opj_event_msg(p_manager, EVT_ERROR, "Stream too short, expected SOT\n");

   if(opj_stream_get_number_byte_left(p_stream) == 0)
 {
   p_j2k->m_specific_param.m_decoder.m_state = J2K_STATE_NEOC;
   return OPJ_TRUE;
 }
   return OPJ_TRUE; /* skip this invalid marker */
  }

}

EXAMPLE 1
=========
bin/opj_decompress -i testcase-2325.jp2 -o testcase.png

===========================================
The extension of this file is incorrect.
FOUND .jp2. SHOULD BE .j2k or .jpc or .j2c
===========================================

[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] Stream too short, expected SOT
[INFO] Tile 1/1 has been decoded.
[INFO] Image data has been updated with tile 1.

Successfully generated Outfile testcase.png

EXAMPLE 2
=========
bin/opj_decompress -i fonzy-file409752.jp2 -o fonzy.png

[INFO] Start to read j2k main header (85).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Psot value of the current tile-part is equal to zero, we assuming it is the
last tile-part of the codestream.
[INFO] Header of tile 0 / 0 has been read.
[ERROR] Stream too short, expected SOT
[INFO] Tile 1/1 has been decoded.
[INFO] Image data has been updated with tile 1.

[INFO] Stream reached its end !
Successfully generated Outfile fonzy.png


winfried

Reported by szukw000 on 2013-07-14 12:52:10

[gcode-importer]

@winfried I cannot possibly accept your suggested patch:

   return OPJ_TRUE; /* skip this invalid marker */

This will accept any kind of invalid J2K codestream. I do not understand why kakadu
is so relaxed. Maybe all output image has been filled and in this case it is valid
to return.

Reported by malaterre on 2014-02-25 13:04:15

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

[gcode-importer]

This issue was updated by revision r2412.

Reported by malaterre on 2014-02-25 13:07:57

[gcode-importer]

This issue was closed by revision r2461.

Reported by malaterre on 2014-02-26 11:16:34

• Status changed: Fixed

[gcode-importer]

Reported by malaterre on 2014-02-28 08:32:35

• Labels added: Milestone-Release2.1

[gcode-importer]

Not fixed (as of r2748)

Reported by malaterre on 2014-03-14 15:54:15

• Status changed: Accepted

[gcode-importer]

regression introduced in r2525

Reported by malaterre on 2014-03-14 15:57:30

[gcode-importer]

Issue 500 has been merged into this issue.

Reported by mayeut on 2015-06-01 15:56:50

[gcode-importer]

Comment from Winfried in issue 500 :
The file 'opj_data/input/nonregression/issue226.j2k' fails
with OPENJPEG, but not with KDU.

The patch for 'openjpeg-2.x-trunk-r3006' is attached.

The marker(0x8080) is skipped in the test 

 opj_stream_get_number_byte_left(p_stream) <= 2

winfried

Reported by mayeut on 2015-06-01 15:58:31

---

- _Attachment: [openjpeg-2.x-trunk-r3006.dif](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-226/comment-11/openjpeg-2.x-trunk-r3006.dif)_