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

[ERROR] COD marker already read. No more than one COD marker per tile. #1043

Closed
beva opened this issue Nov 30, 2017 · 3 comments
Closed

[ERROR] COD marker already read. No more than one COD marker per tile. #1043

beva opened this issue Nov 30, 2017 · 3 comments

Comments

@beva
Copy link

beva commented Nov 30, 2017

Hi

I do experience this error from version 2.3.0 of openjpeg when I decompress. The images in focus are originally created from a bulk scanner. I am talking about millions of images. Previous version 2.1.0 of openjepeg do not have any problems with those images. I have included reports from both opj_dump and jpylyzer, both telling that the images are fine. The behaviour is:

beva@vax04:~/Bilder$ opj_decompress -i db11217051900674.jp2 -o test.png

[INFO] Start to read j2k main header (111).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[ERROR] COD marker already read. No more than one COD marker per tile.
[ERROR] Fail to read the current marker segment (0xff52)
[ERROR] Failed to decode the codestream in the JP2 file
ERROR -> opj_decompress: failed to decode image!

I then downloaded the source (version 2.3.0) and found the part in the code which is responsible for this behaviour. In src/lib/openjp2/j2k.c at about line 2660 you will find this code snippet:

    /* Only one COD per tile */

    if (l_tcp->cod) {
        opj_event_msg(p_manager, EVT_ERROR,
                      "COD marker already read. No more than one COD marker per tile.\n");
        return OPJ_FALSE;
    }
    l_tcp->cod = 1;

Commenting out this snippet, letting only "l_tcp->cod = 1;" be active, or change "if (l_tcp->cod)" to "if (l_tcp->cod > 1)" and then compile the code, it will decompress my files without any problems.

I am not experienced in C or the JPEG2000 standard, however it seems that the test for multiple COD's may be broken somehow. Could it be that "l_tcp->cod" is not nilled between tiles?

If the test turns out to be logically correct, and thus my files in fact violates the JPEG2000, could it just be better to spawn a warning during decompression, instead of a show stopper action. Further on, in this case, should opj_dump gives a message of violation and not telling that the file is fine.

With very best regards

Bent, Oslo, Norway

Anlyzes_of_jpeg2000_image.txt

@rouault
Copy link
Collaborator

rouault commented Nov 30, 2017

Could you provide a link to such an image for further investigations ?

@beva
Copy link
Author

beva commented Nov 30, 2017

I have put an example at dropbox, and even a decompressed png version.

https://www.dropbox.com/sh/kybf40i7v2cfoan/AAC0g1mEIz7w8YPmm-_Nnw5Ja?dl=0

Bent

rouault added a commit to uclouvain/openjpeg-data that referenced this issue Nov 30, 2017
rouault added a commit to uclouvain/openjpeg-data that referenced this issue Nov 30, 2017
@rouault
Copy link
Collaborator

rouault commented Dec 2, 2017

@mayeut Should have CC'ed you since you authored daed8cc9195555e101ab708a501af2dfe6d5e001which I've basically reverted per 98cfdd3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants