uclouvain / openjpeg

Official repository of the OpenJPEG project
Other
970 stars 455 forks source link

Number of resolutions is too high in comparison to the size of tiles #215

Open gcode-importer opened 11 years ago

gcode-importer commented 11 years ago

Originally reported on Google Code with ID 215

image_to_j2k -i 500px.png -o 500px.png.jp2

[INFO] tile number 1 / 1
[INFO] - tile encoded in 0.003000 s
Generated outfile 500px.png.jp2

./opj_compress -i 500px.png -o kaputt.jp2

/sources/LIB/OPENJPEG/TRUNK/openjpeg-trunk-r2322-1/src/lib/openjp2/j2k.c:6453:
        NUMRESOLUTIONS(64) TDX(71) TDY(35)
[ERROR] 6436:Number of resolutions is too high in comparison to the size of tiles
failed to encode image: opj_start_compress
failed to encode image: opj_encode
failed to encode image: opj_end_compress
failed to encode image

Both are r2322.

winfried

Reported by szukw000 on 2013-03-29 12:56:59


gcode-importer commented 10 years ago

Reported by malaterre on 2014-02-25 11:08:59

gcode-importer commented 10 years ago
confirmed over here. Here is what I have:

$ ./bin/opj_compress -i 500px.png -o kaputt.jp2

[ERROR] Number of resolutions is too high in comparison to the size of tiles
failed to encode image: opj_start_compress
failed to encode image: opj_encode
failed to encode image: opj_end_compress
failed to encode image

Reported by malaterre on 2014-02-25 11:09:41

gcode-importer commented 10 years ago
The following will work:

opj_compress -n 5 -i 500px.png -o kaputt.jp2

but this one will fails:

opj_compress -n 6 -i 500px.png -o kaputt.jp2

For some reason openjpeg reject the second case since dimension of PNG is 

$ pnginfo 500px.png | head -2
500px.png...
  Image Width: 71 Image Length: 35

In which case 35 is smaller than 2^6 (64)

Reported by malaterre on 2014-02-25 11:17:59

gcode-importer commented 10 years ago
openjpeg 1.5 seems to handle the number of resolutions of 6 quite nicely.

Reported by malaterre on 2014-02-25 11:18:59

gcode-importer commented 10 years ago

Reported by malaterre on 2014-02-25 16:25:42

gcode-importer commented 10 years ago

Reported by malaterre on 2014-02-27 11:21:53

gcode-importer commented 10 years ago

Reported by malaterre on 2014-03-03 08:09:12

gcode-importer commented 10 years ago

Reported by malaterre on 2014-03-14 14:03:52

gcode-importer commented 9 years ago
Tried to encode a 32x32 image with Kakadu for levels 0 to 32 (-n 1 to 33 for OpenJPEG)
=> no complain.
Tried to decode with opj_decompress those images :
- 0 to 5, OK, no complain.
- 6 to 30, OK, warning in tgt_create tree->numnodes == 0, no tree created.
- 31, OK, same warning but in dwt decode, we can see negative x0, x1, y0, y1 for the
first resolution decoded (leading to a 1x1 block which is probably why result is OK)
- 32, KO, same warnings

Trying to encode the same image with OpenJPEG using levels 0 to 32 (-n 1 to 33) (removing
the checks):
- 0 to 5, OK, no complain.
- 6 to 18, 20 to 28, 30 to 31, OK, warning in tgt_create tree->numnodes == 0, no tree
created.
- 19, 29 : same warning, no error but image colors are off...
- 32 : heap-buffer-overflow src/lib/openjp2/dwt.c:291 opj_dwt_encode_1

I will only update to correct the check which doesn't take into account the adjustment
by 1.

Reported by mayeut on 2014-12-19 22:23:23

gcode-importer commented 9 years ago
This issue was updated by revision r2963.

Reported by mayeut on 2014-12-19 22:56:06

gcode-importer commented 9 years ago
This issue was updated by revision r2964.

Reported by mayeut on 2014-12-19 22:56:17

mayeut commented 9 years ago

I did the same test as before after commit 38770403d49528936fae44de5fc6089f0bf0c3e9 Result is now:

Tried to encode a 32x32 image with Kakadu for levels 0 to 32 (-n 1 to 33 for OpenJPEG) => no complain. Tried to decode with opj_decompress those images :

Trying to encode the same image with OpenJPEG using levels 0 to 32 (-n 1 to 33) (removing the checks):