Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot handle box of undefined size #653

Closed
smuehlst opened this issue Nov 5, 2015 · 1 comment
Closed

Cannot handle box of undefined size #653

smuehlst opened this issue Nov 5, 2015 · 1 comment
Assignees
Labels
Milestone

Comments

@smuehlst
Copy link
Contributor

smuehlst commented Nov 5, 2015

I had asked about this issue on the mailing list, but got no reply.

How to reproduce:

Save the attached file as "gradient.trailingzeros.jp2" (file was attached as .jpg file because GitHub doesn't know JPEG 2000 files):
gradient trailingzeros jp2

The file was created by appending a block of zero bytes to an existing JPEG 2000 file.

Run opj_decompress:

$ bin/opj_decompress -i gradient.trailingzeros.jp2 -o gradient.trailingzeros.tif

[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] Header of tile 1 / 1 has been read.
[INFO] Tile 1/1 has been decoded.
[INFO] Image data has been updated with tile 1.

[ERROR] Cannot handle box of undefined sizes
ERROR -> opj_decompress: failed to decode image!

The claim is that the test file is a valid JPEG 2000 file according to 15444-1. From ISO 15444-1, "I.8 Dealing with unknown boxes":

"An unknown box is a box that is not defined in this Recommendation | International Standard. A conforming JP2 file may contain unknown boxes. If a conforming reader finds an unknown box, it shall skip and ignore that box."

The zeroes after the last box in the original file can be interpreted as another box with LBox=0000 and TBox=0000, meaning a box of unspecified length with type 0000. As the box with unspecified length appears at the end of the file, and the original file has a "jp2c" Contiguous Code-Stream box as the last box with an explicit size, this is allowed. Type 0000 is unknown, so the box should be ignored.

jpylyzer recognizes the file as a valid JPEG 2000 file, and shows the trailing zeros as an unknown box:

    <unknownBox>
        <boxType/>
    </unknownBox>

Expected result: OpenJPEG should interpret the trailing zeros as a box of unknown size with an unknown type, and should successfully decompress the test file.

@mayeut
Copy link
Collaborator

mayeut commented Nov 5, 2015

@smuehlst, this is indeed a bug.
Section I.4 of 15444-1 also states how to handle 0 length box.
It sums up as, this is the last box of the file and as such contains all data up to the end of the file. It doesn't matter if the box is known or unknown. I guess tests shall be added with such data.

@mayeut mayeut added the bug label Nov 5, 2015
mayeut added a commit to mayeut/openjpeg-data that referenced this issue Nov 7, 2015
@mayeut mayeut added this to the OPJ v2.1.1 milestone Nov 7, 2015
@mayeut mayeut self-assigned this Nov 7, 2015
mayeut added a commit to mayeut/openjpeg that referenced this issue Nov 7, 2015
@mayeut mayeut closed this as completed Nov 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants