#3139 closed defect (invalid)
Assertion `!sp->cinfo.comm.is_decompressor' in r17637
Reported by: | timlinux | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | gtiff |
Cc: |
Description
I'm trying to build pyramids / overviews on a vrt dataset but I get an assertion error each time.
e.g.
gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL mosaic.vrt 2 4 8 16 0...10...20...30...40...gdaladdo: tif_jpeg.c:691: JPEGPreDecode: Assertion `sp->cinfo.comm.is_decompressor' failed
or
gdaladdo --config COMPRESS_OVERVIEW JPEG --config INTERLEAVE_OVERVIEW PIXEL mosaic.vrt 2 4 8 16 0gdaladdo: tif_jpeg.c:1299: JPEGPreEncode: Assertion `!sp->cinfo.comm.is_decompressor' failed. Aborted (core dumped)
This seems to be similar symptoms to closed bug #2033
This issue was encountered with svn trunk r17637
I have in the past successfully built overviews on vrt datasets so I am guessing the activity itself is supported.
Tim
Change History (3)
comment:1 by , 15 years ago
Component: | default → GDAL_Raster |
---|---|
Keywords: | gtiff added |
Milestone: | 1.7.0 |
Status: | new → assigned |
comment:2 by , 15 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
Hi
My system (Ubuntu Karmic 9.10 i386) has the following tiff libs:
ii libtiff4 3.8.2-13 Tag Image File Format (TIFF) library ii libtiff4-dev 3.8.2-13 Tag Image File Format library (TIFF), develo ii libtiffxx0c2 3.8.2-13 Tag Image File Format (TIFF) library -- C++
I configured gdal and built it like this:
cd <gdal src> make clean ./configure --with-ecw=/usr/local make -j8 sudo make install
Which results in this config:
LIBTIFF support: external (BigTIFF=no) LIBGEOTIFF support: internal
I then rebuilt using:
./configure --with-libtiff=internal --with-geotiff=internal --with-ecw=/usr/local
I tested building a few pyramids and it seemed to resolve the problem. I was wondering if there is any good reason why the internal libtiff isn't used by default if the external lib cant be relied on to work correctly.
Many thanks
Regards
Tim
comment:3 by , 15 years ago
Tim,
There are bad things that can happen if a higher level application links in the system libtiff and the internal libtiff in GDAL so it is generally preferred that GDAL be linked with the system libtiff.
Tim,
Is this when building with the internal libtiff and libgeotiff libraries? This issue can arise if using older system libtiff's even with GDAL svn trunk.