[gdal-dev] Issue with gdalchksum on Fedora 21 ppc64le?

Sun Aug 23 20:16:50 PDT 2015

Thanks a lot for you response Even
out.asc is clearly different on the two platforms (x86 and ppc64le).

On x86 the content is as follows:
ncols        20
nrows        20
xllcorner    440720.000000000000
yllcorner    3750120.000000000000
cellsize     60.000000000000
 107 123 132 115 132 132 140 132 132 132 107 132 107 132 132 107 123 115 156 148
 115 132 107 123 148 115 165 115 140 107 123 123 99 132 123 132 132 132 99 156
 115 132 140 132 123 115 140 107 140 115 132 123 107 132 132 115 115 107 115 107
 148 132 123 123 115 132 132 123 115 123 115 123 107 115 148 107 115 140 115 132
 132 156 132 140 132 132 115 115 115 123 148 123 165 123 132 107 107 132 156 123
 189 173 173 148 148 115 148 123 107 132 115 132 156 99 123 115 132 132 206 107
 197 173 148 140 140 132 99 132 123 115 140 132 132 99 132 123 132 173 123 115
 148 123 148 115 148 123 140 123 107 115 132 115 107 115 99 123 99 181 99 107
 123 115 132 115 123 132 115 132 132 123 123 132 99 115 99 123 132 115 115 107
 140 140 99 140 99 115 123 107 132 107 115 107 115 123 132 123 107 123 132 132
 132 132 132 123 99 132 123 107 148 99 115 123 140 173 123 107 123 123 123 107
 123 123 123 107 140 123 123 115 115 90 107 173 107 107 107 107 99 132 123 115
 173 148 99 123 123 107 123 99 107 189 173 107 115 115 107 99 140 107 173 140
 148 132 132 107 123 99 99 115 99 132 99 140 115 148 123 99 132 123 148 140
 140 107 140 90 107 115 107 90 99 123 115 115 115 123 123 148 115 148 99 132
 165 148 156 123 107 107 107 115 140 99 115 99 99 107 115 132 115 90 123 115
 189 173 140 140 165 115 132 90 99 115 90 99 99 107 99 132 99 107 132 132
 156 181 140 173 123 132 99 115 123 74 115 99 123 140 156 132 165 140 140 99
 173 247 255 206 132 107 140 123 148 132 165 165 148 140 132 123 107 123 107 123
 181 181 156 148 156 156 156 181 132 148 115 132 107 107 107 107 107 115 99 107

On ppc64le:
ncols        20
nrows        20
xllcorner    440720.000000000000
yllcorner    3750120.000000000000
cellsize     60.000000000000
 107 123 132 371 388 388 396 644 644 644 875 900 1131 1156 1156 1387
1403 1651 1692 1940
 115 132 363 379 404 627 677 883 908 1131 1147 1147 1379 1412 1659
1668 1668 1668 1891 1948
 115 132 140 388 635 883 908 1131 1164 1395 1412 1659 1899 1924 1924
2163 2163 2411 2419 2667
 148 388 635 635 883 900 900 1147 1395 1403 1651 1659 1899 1907 1940
2155 2163 2188 2419 2436
 132 156 388 396 644 644 883 883 883 891 916 1147 1189 1403 1412 1643
1643 1668 1692 1915
 189 429 429 660 660 883 916 1147 1387 1412 1651 1668 1692 1891 1915
2163 2180 2180 2254 2411
 197 429 660 908 908 1156 1379 1412 1659 1907 1932 2180 2180 2403 2436
2683 2692 2733 2939 3187
 148 379 404 627 660 891 908 1147 1387 1395 1412 1651 1899 1907 2147
2171 2403 2485 2659 2667
 123 371 388 627 635 644 883 900 900 1147 1147 1156 1379 1395 1635
1659 1668 1907 1907 2155
 140 140 355 396 611 627 635 875 900 1131 1139 1387 1395 1403 1412
1659 1899 1915 1924 1924
 132 132 132 379 611 644 891 1131 1172 1379 1395 1403 1420 1453 1659
1899 1915 1915 1915 2155
 123 123 123 363 396 635 635 883 883 1114 1131 1197 1387 1387 1387
1387 1635 1668 1915 2163
 173 404 611 635 635 875 891 1123 1131 1213 1453 1643 1651 1651 1899
2147 2188 2411 2477 2700
 148 388 388 619 635 867 867 883 1123 1156 1379 1420 1651 1684 1915
2147 2180 2427 2452 2700
 140 363 396 602 619 627 875 1114 1123 1147 1395 1395 1395 1403 1403
1428 1651 1684 1891 1924
 165 404 412 635 875 875 875 883 908 1123 1139 1379 1379 1387 1395
1412 1651 1882 1915 2163
 189 429 652 652 677 883 900 1114 1123 1139 1370 1379 1379 1387 1635
1668 1891 1899 1924 1924
 156 181 396 429 635 644 867 883 891 1098 1139 1379 1403 1420 1436
1668 1701 1932 1932 2147
 173 247 255 462 644 875 908 1147 1172 1412 1445 1445 1684 1932 2180
2427 2667 2683 2923 2939
 181 181 412 660 668 668 668 693 900 916 1139 1156 1387 1387 1387 1387
1387 1395 1635 1643

I will try to dig into this more. Thanks!

On Sat, Aug 22, 2015 at 1:57 AM, Even Rouault
<even.rouault at spatialys.com> wrote:
> Le vendredi 21 août 2015 07:01:41, Gawade P a écrit :
>>  Hi All,
>>
>> I am performing the following operation on a Fedora 21 ppc64le machine:
>>
>> gdal_translate -of HF2 byte.tif byte.tif.tst
>>
>> Here byte.tiff is TIFF image data
>> [root at pts0433-vm12 test]# file byte.tif
>> byte.tif: TIFF image data, little-endian, direntries=15, height=20,
>> bps=8, compression=none, PhotometricIntepretation=BlackIsZero,
>> width=20
>>
>> The operation completes without issues.
>>
>> However,
>> gdalchksum.py byte.tif
>>  gives me 4672
>>
>> and
>> gdalchksum.py byte.tif.tst
>> give me 4716
>>
>> I have installed gdal and gdal-python using the following rpm packages:
>> gdal-1.11.2-4.fc21.ppc64le.rpm
>> gdal-python-1.11.2-4.fc21.ppc64le.rpm
>>
>> The above commands give the same output on Intel (x86) platform i.e. 4672.
>> Also, if I transfer the output file byte.tif.tst to an x86 machine, I
>> get the correct output, i.e. 4672.
>>
>> Can anyone please guide me on what is the expected output
>
> In theory this should be 4672 on all platforms. The behaviour you get would
> mean that the writing side is OK on PPC64LE, but the reading side is not.
>
> The issue is probably in HF2RasterBand::IReadBlock() in
> frmts/hf2/hf2dataset.cpp if you want to give a try to debug it.
>
> A quick way of having an overview of the differences would be to run the
> following on x86 and PPC64LE and compare out.asc:
>
> gdal_translate byte.tif.tst out.asc -of aaigrid
>
>>
>> Thanks in advance!
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com