image rejected for padding(?)

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by zeniko on 14 Jun 2013 at 7:47

Attachments:

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

[GoogleCodeExporter]

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

Original comment by szukw...@arcor.de on 29 Jun 2013 at 8:12

Attachments:

• openjpeg-trunk-r2343-5-jk2.c.dif.gz
• openjpeg-branch15-r2343-3.dif.gz

[GoogleCodeExporter]

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

winfried

Original comment by szukw...@arcor.de on 30 Jun 2013 at 12:06

[GoogleCodeExporter]

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

Original comment by szukw...@arcor.de on 14 Jul 2013 at 12:52

[GoogleCodeExporter]

@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.

Original comment by mathieu.malaterre on 25 Feb 2014 at 1:04

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This issue was updated by revision r2412.

Original comment by mathieu.malaterre on 25 Feb 2014 at 1:07

[GoogleCodeExporter]

This issue was closed by revision r2461.

Original comment by mathieu.malaterre on 26 Feb 2014 at 11:16

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 28 Feb 2014 at 8:32

• Added labels: Milestone-Release2.1

[GoogleCodeExporter]

Not fixed (as of r2748)

Original comment by mathieu.malaterre on 14 Mar 2014 at 3:54

• Changed state: Accepted

[GoogleCodeExporter]

regression introduced in r2525

Original comment by mathieu.malaterre on 14 Mar 2014 at 3:57