format georaster ERROR 1: ZLib return code (-3)

[lucafibbi]

On a Linux operating system with LSB byte order when reading an georaster image with the deflate compression appears the error: ERROR 1: ZLib return code (-3)

The error disappears when inside the function GeoRasterWrapper::GetDataBlock (georaster_wrapper.cpp) the following statements are executed after UncompressDeflate call:

# ifndef CPL_MSB

if (nCellSizeBits> 8) {

int = nWordSize nCellSizeBits / 8; nWordCount nColumnBlockSize = int * * nRowBlockSize nBandBlockSize; GDALSwapWords (pabyBlockBuf, nWordSize, nWordCount, nWordSize);

}

# endif

[ilucena]

I am a little bit confused. If we look at the lines above, the BLOB content was already swapped once, before UncompressDeflate. [ http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/georaster/georaster_wrapper.cpp#L1926 ]

The error message most be coming from the call to uncompress() inside UncompressDeflate. So I can't understand how by adding code after uncompress() would fix that.

Is that what you mean by after UncompressDeflate:

        if( EQUALN( sCompressionType.c_str(), "JPEG", 4 ) )
        {
            UncompressJpeg( nBytesRead );
        }
        else if ( EQUAL( sCompressionType.c_str(), "DEFLATE" ) )
        {
            UncompressDeflate( nBytesRead );
#ifndef CPL_MSB
            if( nCellSizeBits > 8 )
            {
                int nWordSize  = nCellSizeBits / 8;
                int nWordCount = nColumnBlockSize * nRowBlockSize * nBandBlockSize;
                GDALSwapWords( pabyBlockBuf, nWordSize, nWordCount, nWordSize );
            }
#endif
        }

Thanks for pointing that out.

[lucafibbi]

I do not know the exact reasons for the error, but on my system, the original code of the gdal (version 1.8.1) produces the message:
ERROR 1: ZLib return code (-3)
after reading an georaster image compressed with the deflated algorithm.
This print is produced by the UncompressDeflate function becouse the uncompress function returns with the error -3 (Z_DATA_ERROR) that indicates the input data was corrupted or incomplete.
The read image was written in Oracle using the same georaster driver of the 1.8.1 library gdal.
Looking at the changes made following to the report (http://trac.osgeo.org/gdal/ticket/3763) and noting that on my system is executing the code within of the define
# ifndef CPL_MSB
I tried to move this code after the UncompressDeflate function call. After this changes the error is gone and the image was read correctly.
Within GeoRasterWrapper::SetDataBlock the order in which functions are called is:
GDALSwapWords
UncompressDeflate
so I presume that in GeoRasterWrapper::GetDataBlock the order should be reversed.
I am not able to perform tests on various systems (LSB and MSB) and with the various compression algorithms (JPEG and deflate) and therefore are not able to indicate what is the exact point where to execute the swap in GeoRasterWrapper::GetDataBlock.

I hope I have clarified when I could understand.

[ilucena]

That makes more sense: "I tried to *move* this code after the UncompressDeflate? function call. After this changes the error is gone and the image was read correctly."

The keyword for me is move. That means that you remove the swap bytes that occurs before uncompress and move it to after uncompress.

That means that in LSB platform we should not swap bytes before zlib uncompress. Right?

Does is it means that we need to swap after uncompress? How does the image looks like?

Thank you so very much for your help.

[lucafibbi]

Replying to ilucena:

That makes more sense: "I tried to *move* this code after the UncompressDeflate? function call. After this changes the error is gone and the image was read correctly."

The keyword for me is move. That means that you remove the swap bytes that occurs before uncompress and move it to after uncompress.

Yes.

That means that in LSB platform we should not swap bytes before zlib uncompress. Right?

Yes.

Does is it means that we need to swap after uncompress? How does the image looks like?

When I tried to delete the code with instructions for swapping the values ​​of the image were incorrect, while with the swap code after the decompression the values are ​​equal to the original image prior to insertion in the Oracle.

Thank you so very much for your help.

[ilucena]

Are you building GDAL with the internal ZLib?

[lucafibbi]

Replying to ilucena:

Are you building GDAL with the internal ZLib?

No. Here the my configure report:

GDAL is now configured for i686-pc-linux-gnu

Installation directory: /usr/local C compiler: gcc -g -DDEBUG C++ compiler: g++ -g -DDEBUG

LIBTOOL support: yes

LIBZ support: external LIBLZMA support: no GRASS support: no CFITSIO support: no PCRaster support: internal NetCDF support: yes LIBPNG support: external LIBTIFF support: internal (BigTIFF=yes) LIBGEOTIFF support: internal LIBJPEG support: external 8/12 bit JPEG TIFF: no LIBGIF support: internal OGDI support: no HDF4 support: yes HDF5 support: yes Kakadu support: no JasPer support: no OpenJPEG support: no ECW support: no MrSID support: no MrSID/MG4 Lidar support: no MSG support: yes GRIB support: yes EPSILON support: no cURL support (wms/wcs/...):yes PostgreSQL support: no MySQL support: no Ingres support: no Xerces-C support: yes NAS support: yes Expat support: yes Google libkml support: no ODBC support: yes PGeo support: yes PCIDSK support: internal OCI support: yes GEORASTER support: yes SDE support: no Rasdaman support: no DODS support: no SQLite support: no SpatiaLite support: no DWGdirect support no INFORMIX DataBlade support:no GEOS support: yes VFK support: yes Poppler support: no OpenCL support: no

SWIG Bindings: no

Statically link PROJ.4: no enable OGR building: yes enable pthread support: yes hide internal symbols: no

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.