[gdal-dev] Strange behaviour of gdal_translate with ECW on linux (libecw 3.3)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Strange behaviour of gdal_translate with ECW on linux (libecw 3.3)

Sylvain Maffren
Hi,

I try to convert RGB tiff file (300 Mo) into ECW ( libecw 3.3 and gdal 1.8.1 that I have compiled) using this gdal_translate command, on a Debian Squeeze :  gdal_translate -of "ECW" -co LARGE_OK="YES" -co TARGET="90" -co DATUM="RGF93" -co PROJ="LMFRAN93" file_in.tif file_out.ecw, and I get strange results.

When I compare this results with ECW images that I get with the same command and the same source image with Windows binaries obtained here : http://www.gisinternals.com/sdk/, MacOSX binaries obtained here : http://www.kyngchaos.com/software: frameworks and translation with ErMapper with the same target, I note some differences between Linux results and other platforms results.

The result on Linux seems to be fuzzy, with poorer quality and a comparison with gdalinfo –mm –checksum confirm that fact (images – comparative tables downloadable here : http://dl.free.fr/mkXpXahz3 - link "Télécharger ce fichier"). I also used this command with Linux binaries (FWTOOLS Linux 2.0.6) and the same differences are appearing. I try with Windows binaries 64 bits and the result is comparable to the linux one (Nevertheless it’s perfect with 32 bits binaries).

I tried with “libecwj2-3.3-2006-09-06.zip” and “ImageCompressionSDKSourceCode3.3Setup_20070509.zip” source code, I have as well tried to apply all the patches I found on the web. It doesn’t change anything. I also tried to compile libECW 3.3 on FreeBSD (which is quite same as MacOSX), without best results…

I posted this question on a French forum (http://www.forumsig.org/showthread.php?p=286890#post286890) and others users do the same observations.

With the decompression process (ECW to Tiff with GDAL_TRANSLATE), I have the same and good result on each platform.

It’s seems that the only problem relies on the ECW compression on Linux, with 3.3 SDK version (I compiled examples in source tree of SDK 3.3 and I have done some tests: it seems that the ECW compression with SDK is bad too. That would mean this problem not appears with GDAL…?).

Does anybody know this problem ? If not, it would maybe be interesting to add this information in GDAL WIKI in order to prevent users of lib 3.3 (I don’t have an account to edit this page).

All ideas and remarks are welcome. I’m not C/C++ developer and it’s very difficult for me to find an issue…

Best regards,

Sylvain

--
-------------------------------------

Sylvain MAFFREN
Géomaticien

Tél : 04 42 90 71 22
Fax : 04 42 97 11 56


CRIGE PACA
Domaine du Petit Arbois - Avenue Louis Philibert
BP 10019 - 13 545 Aix-en-Provence cedex 4

www.crige-paca.org

 


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: [gdal-dev] Strange behaviour of gdal_translate with ECW on linux (libecw 3.3)

andreaerdna
Sylvain Maffren wrote
I try to convert RGB tiff file (300 Mo) into ECW ( libecw 3.3 and gdal
1.8.1 that I have compiled) using this gdal_translate command, on a
Debian Squeeze :  gdal_translate -of "ECW" -co LARGE_OK="YES" -co
TARGET="90" -co DATUM="RGF93" -co PROJ="LMFRAN93" file_in.tif
file_out.ecw, and I get strange results.

Hi Sylvain,
I also am doing some tests about ECW encoding with GDAL using different OS (Windows XP 32 bit / Windows 7 64 bit / Linux Ubuntu 10.04 64 bit), different GDAL versions and ECW plugin (1.9.0 / 1.8.1 / 1.8.0 / 1.7.3 / 1.7.0b2) from different origins (www.gisinternals.com / OSGeo4W / FWTools / ubuntugis launchpad repository / ERDAS sources), and with or without a TARGET creation option set.

I'll post the results as soon as the tests are completed.


Andrea Giudiceandrea
Reply | Threaded
Open this post in threaded view
|

Re: [gdal-dev] Strange behaviour of gdal_translate with ECW on linux (libecw 3.3)

andreaerdna
I've done some tests using a PNG image (22080x11520 pixels, 4 bands, 469.969.142 bytes) as source dataset.


Testing Operative Systems are:

1) MS Windows 7 HP SP1 64-bit
2) Ubuntu Linux 10.04 64-bit (kernel 2.6.32-38.83)
3) MS Windows XP Pro SP3 32-bit


Testing GDAL versions are:

1) builds for Windows from www.gisinternals.com/sdk [with related 3.3 ECW plugin]:
GDAL 1.9.0 [64-bit] (release-1600-x64-gdal-1-9-0-mapserver-6-0-1)
GDAL 1.9.0 [32-bit] (release-1600-gdal-1-9-0-mapserver-6-0-1)
GDAL 1.8.1 [64-bit] (release-1600-x64-gdal-1-8-1-mapserver-6-0-1)
GDAL 1.8.1 [32-bit] (release-1600-gdal-1-8-1-mapserver-6-0-1)
GDAL 1.8.0 [64-bit] (release-1600-x64-gdal-1-8-0-mapserver-6-0-0)
GDAL 1.8.0 [32-bit] (release-1600-gdal-1-8-0-mapserver-6-0-0)
GDAL 1.7.3 [64-bit] (release-1600-x64-gdal-1-7-3-mapserver-5-6-5)
GDAL 1.7.3 [32-bit] (release-1600-gdal-1-7-3-mapserver-5-6-5)

2) builds for Ubuntu 10.04 64 bit from UbuntuGis repository [using the ECW libecwj2 3.3 library built by myself from ERDAS SDK Source Code libecwj2-3.3-2006-09-06.zip]:
GDAL 1.9.0 [64 bit] (gdal-bin 1.9.0-1~exp1~lucid3 / libgdal-ecw-src 1.9.0-2~lucid1 / libgdal-dev 1.9.0-1~exp1~lucid3)
GDAL 1.8.0 [64 bit] (gdal-bin 1.8.0-2~lucid2 / libgdal-ecw-src 1.8.0-2~lucid1 / libgdal1-dev 1.8.0-2~lucid3)

3) build for Windows from OSGeo4W [with 3.3 ECW plugin from release-1500-gdal-1-8-1-mapserver-6-0-1 at www.gisinternals.com/sdk]:
GDAL 1.8.1 [32-bit] (gdal 1.8.1-5)

4) build for Windows from FWTools [with related ECW plugin]:
GDAL 1.7.0b2 [32-bit] (FWTools 2.4.7)



Results:

- all 64-bit GDAL versions/builds on 64-bit Operative Systems (both Windows and Linux) tested using gdal_translate with "TARGET=70" creation option behave the same way producing an output ECW file of 159.832.544 bytes (with the same checksums);

- almost all 64-bit GDAL versions/builds on 64-bit Operative Systems (both Windows and Linux) tested using gdal_translate without a "TARGET" creation option behave the same way producing an output ECW file of 24.982.036 bytes (with the same checksums) with the only exception of GDAL 1.7.3 [64-bit] (from www.gisinternals.com/sdk) on Windows 7 64-bit that produces a considerably different (about 5 time bigger) output ECW file of 129.634.758 bytes;

- all 32-bit GDAL versions/builds on 64-bit/32-bit Windows tested using gdal_translate with "TARGET=70" creation option behave the same way producing an output ECW file of 192.085.632 bytes (with the same checksums) that is slightly bigger than that produced by 64-bit GDAL versions with the same "TARGET=70" creation option;

- the 32-bit GDAL versions/builds 1.9.0, 1.8.1, 1.8.0 from www.gisinternals.com/sdk and 1.8.1 from OSGeo4W on 64-bit/32-bit Windows tested using gdal_translate without a "TARGET" creation option behave the same way producing an output ECW file of 52.777.560 bytes (with the same checksums);

- the 32-bit GDAL versions/builds 1.7.3 from www.gisinternals.com/sdk and 1.7.0b2 from FWTools 2.4.7 on 64-bit/32-bit Windows tested using gdal_translate without a "TARGET" creation option behave the same way producing an output ECW file of 164.417.131 bytes (with the same checksums) that is about 3 times bigger than that produced by the other 32-bit GDAL versions tested.



I hope to do further investigation in the coming days


Andrea Giudiceandrea
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of gdal_translate with ECW on linux (libecw 3.3)

Jean-Claude Repetto
On 02/28/12 02:15, andreaerdna wrote:

> - the 32-bit GDAL versions/builds 1.7.3 from www.gisinternals.com/sdk and
> 1.7.0b2 from FWTools 2.4.7 on 64-bit/32-bit Windows tested using
> gdal_translate without a "TARGET" creation option behave the same way
> producing an output ECW file of 164.417.131 bytes (with the same checksums)
> that is about 3 times bigger than that produced by the other 32-bit GDAL
> versions tested.
>

Hi,
The default TARGET parameter value has been changed from 75% to 95%
between GDAL 1.7.3 and GDAL 1.8.
So please allways give the TARGET parameter when you make your tests,
and use the same TARGET for all your tests.

It would be useful if you can make your test image available to
everybody, so that people can compare their results with yours. If it is
not possible, use a freely available image, such as NASA BlueMarble.

Could you also test on Linux 32 bits ?

Best regards,
Jean-Claude
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of gdal_translate with ECW on linux (libecw 3.3)

Sylvain Maffren
Hi,

And thanks for your tests
! For those who want to make some tests with the same file than me (tiff RGB - 293 Mo), I published it on a FTP server :

Adress : ftp://interne.crige-paca.org
Login : gdaldevecw
Password :
ftc65*gt

I also published in this FTP the comparative table of my tests and results. I agree with Jean-Claude. It could be great to make tests with the same original file and the same gdal_translate command (gdal_translate -of "ECW" -co LARGE_OK="YES" -co TARGET="90" -co DATUM="RGF93" -co PROJ="LMFRAN93" file_in.tif file_out.ecw).

I made some complementary tests on GDAL 1.9 (Windows-Linux-MacOSX / 32-64 bits) and always get the same differencies...

Best regards,

Sylvain

--
-------------------------------------

Le 28/02/2012 08:28, Jean-Claude Repetto a écrit :
On 02/28/12 02:15, andreaerdna wrote:

- the 32-bit GDAL versions/builds 1.7.3 from www.gisinternals.com/sdk and
1.7.0b2 from FWTools 2.4.7 on 64-bit/32-bit Windows tested using
gdal_translate without a "TARGET" creation option behave the same way
producing an output ECW file of 164.417.131 bytes (with the same checksums)
that is about 3 times bigger than that produced by the other 32-bit GDAL
versions tested.


Hi,
The default TARGET parameter value has been changed from 75% to 95% between GDAL 1.7.3 and GDAL 1.8.
So please allways give the TARGET parameter when you make your tests, and use the same TARGET for all your tests.

It would be useful if you can make your test image available to everybody, so that people can compare their results with yours. If it is not possible, use a freely available image, such as NASA BlueMarble.

Could you also test on Linux 32 bits ?

Best regards,
Jean-Claude
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Strange behaviour of gdal_translate with ECW on linux (libecw 3.3)

Jean-Claude Repetto
Le 28/02/2012 10:52, Sylvain MAFFREN a écrit :
> Hi,
>
> And thanks for your tests ! For those who want to make some tests with
> the same file than me (tiff RGB - 293 Mo),I published it on a FTP server

My results on Gentoo Linux 64 bits and GDAL 1.9.0 :

Size = 16706521

Band 1
   Minimum=0.000, Maximum=255.000, Mean=110.714, StdDev=51.019
   Checksum=26447
Band 2
   Minimum=0.000, Maximum=255.000, Mean=107.029, StdDev=45.057
   Checksum=18380
Band 3
   Minimum=0.000, Maximum=255.000, Mean=91.003, StdDev=43.803
   Checksum=9105

Jean-Claude
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev