[gdal-dev] Reading JPEG2000 file related to drivers

Even Rouault even.rouault at spatialys.com
Tue Oct 13 08:25:50 PDT 2015


Le mardi 13 octobre 2015 17:04:19, Yves Jacolin a écrit :
> Hello,
> 
> On Tuesday, October 13, 2015 13:23:05 Yves Jacolin wrote:
> > [..]
> > 
> > Do you know any limitation on jp2OpenJpeg? I get a segmentation fault
> > with this driver:
> > 
> > Here is the bt (from gdal 1.11, but get almost the same from trunk, line
> > number is different):
> > [..]
> 
> Sorry to spam you :)
> 
> We tested with a jp2 file from autotest directory: 3_13bit_and_1bit.jp2,
> OpenJpeg lib 2.0 and GDAL 1.11.
> 
> We had the same problem. Building gdal with debug mode we had the following
> debug info:
> 
> GDAL: AutoSkipDriver(JP2ECW)
> OPENJPEG: info: Start to read j2k main header (1427).
> OPENJPEG: info: Main header has been correctly decoded.
> OPENJPEG: nX0 = 0
> OPENJPEG: nY0 = 0
> OPENJPEG: nTileW = 202
> OPENJPEG: nTileH = 308
> OPENJPEG: psImage->x0 = 0
> OPENJPEG: psImage->y0 = 0
> OPENJPEG: psImage->x1 = 202
> OPENJPEG: psImage->y1 = 308
> OPENJPEG: psImage->numcomps = 4
> OPENJPEG: psImage->color_space = 0
> OPENJPEG: numResolutions = 3
> OPENJPEG: psImage->comps[0].dx = 1
> OPENJPEG: psImage->comps[0].dy = 1
> OPENJPEG: psImage->comps[0].x0 = 0
> OPENJPEG: psImage->comps[0].y0 = 0
> OPENJPEG: psImage->comps[0].w = 202
> OPENJPEG: psImage->comps[0].h = 308
> OPENJPEG: psImage->comps[0].resno_decoded = 0
> OPENJPEG: psImage->comps[0].factor = 0
> OPENJPEG: psImage->comps[0].prec = 13
> OPENJPEG: psImage->comps[0].sgnd = 0
> OPENJPEG: psImage->comps[1].dx = 0
> OPENJPEG: psImage->comps[1].dy = 0
> OPENJPEG: psImage->comps[1].x0 = 202
> OPENJPEG: psImage->comps[1].y0 = 308
> OPENJPEG: psImage->comps[1].w = 1
> OPENJPEG: psImage->comps[1].h = 1
> OPENJPEG: psImage->comps[1].resno_decoded = 0
> OPENJPEG: psImage->comps[1].factor = 0
> OPENJPEG: psImage->comps[1].prec = 0
> OPENJPEG: psImage->comps[1].sgnd = 13
> OPENJPEG: psImage->comps[2].dx = 0
> OPENJPEG: psImage->comps[2].dy = 0
> OPENJPEG: psImage->comps[2].x0 = 1
> OPENJPEG: psImage->comps[2].y0 = 1
> OPENJPEG: psImage->comps[2].w = 0
> OPENJPEG: psImage->comps[2].h = 0
> OPENJPEG: psImage->comps[2].resno_decoded = 0
> OPENJPEG: psImage->comps[2].factor = 13
> OPENJPEG: psImage->comps[2].prec = 202
> OPENJPEG: psImage->comps[2].sgnd = 0
> OPENJPEG: psImage->comps[3].dx = 0
> OPENJPEG: psImage->comps[3].dy = 0
> OPENJPEG: psImage->comps[3].x0 = 0
> OPENJPEG: psImage->comps[3].y0 = 0
> OPENJPEG: psImage->comps[3].w = 0
> OPENJPEG: psImage->comps[3].h = 0
> OPENJPEG: psImage->comps[3].resno_decoded = 308
> OPENJPEG: psImage->comps[3].factor = 0
> OPENJPEG: psImage->comps[3].prec = 1
> OPENJPEG: psImage->comps[3].sgnd = 202
> OPENJPEG: Unable to handle that image (2)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000062faf0 in ?? ()
> 
> So gdal or the openjpeg lib mix information (check width and height for
> each bands).
> 
> We updated openjpeg lib to 2.1 and gdalinfo worked as expected.
> 
> We will test gdal 1.10 with OpenJpeg 2.0 to check that the problem is
> already there as we would like to use GDAL 1.10 but I am afraid we should
> use gdal 1.11 and OpenJpeg 2.1.

Yves,

I think someone has already had that issue. I think you're compiling against 
OpenJPEG 2.0 header and are linking against OpenJPEG 2.1 (or the reverse). 
Some structures of openjpeg have changed sizes between both versions and 
result in such a typical mess at runtime.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list