[gdal-dev] Issue with gdalchksum on Fedora 21 ppc64le?
Gawade P
gawade.oefp at gmail.com
Mon Aug 24 22:28:46 PDT 2015
Hi Even,
It looks like I am running into another checksum issue on ppc64le.
Output on ppc64le:
gdalchksum.py ../autotest/gdrivers/data/nwt_grd.grd
28093
32304
19624
25856
Output on x86:
gdalchksum.py ../autotest/gdrivers/data/nwt_grd.grd
28093
33626
20260
25856
There is a mismatch for bands 2 and 3. I am looking at the code in
frmts/northwood/grddataset.cpp. Would this be the right place?
Would you recommend raising an issue for this one as well? Please suggest.
Thanks !
On Mon, Aug 24, 2015 at 3:05 PM, Gawade P <gawade.oefp at gmail.com> wrote:
> Raised ticket at: https://trac.osgeo.org/gdal/ticket/6082#ticket
>
> On Mon, Aug 24, 2015 at 2:32 PM, Even Rouault
> <even.rouault at spatialys.com> wrote:
>> Le lundi 24 août 2015 10:58:49, Gawade P a écrit :
>>> Thanks, Even!
>>> This change solved the issue I was seeing. Appreciate your help on this!
>>
>> Great. Could you please file a ticket about that on
>> https://trac.osgeo.org/gdal/newticket ?
>>
>>>
>>> On Mon, Aug 24, 2015 at 1:18 PM, Even Rouault
>>>
>>> <even.rouault at spatialys.com> wrote:
>>> > Hi,
>>> >
>>> > Looking at the first difference, 371 - 115 = 256. Those gaps of +256
>>> > appear each time a value at col n+1 is lesser than the value at col n
>>> > (when looking the reference x86 data). Knowing that HF2 data is delta
>>> > encoded and that for this row the delta between consecutive values is in
>>> > the [-128,127] range, so elligible for 1 byte delta encoding, I think
>>> > I've found the issue. Apparently (according to
>>> > https://ajax.fedorapeople.org/is-char-signed-or-not.txt), "char" on ppc
>>> > (and other platforms) is "unsigned char", whereas it is "signed char" on
>>> > x86...
>>> >
>>> > Could you try changing line 201 from :
>>> > nVal += ((char*)pabyData)[i-1];
>>> >
>>> > to
>>> >
>>> > nVal += ((signed char*)pabyData)[i-1];
>>> >
>>> > For clarity, on the encoding side, lines 963 and 1032 that have
>>> >
>>> > char chDiff = (char)nDiff;
>>> >
>>> > should be changed to
>>> >
>>> > signed char chDiff = (signed char)nDiff;
>>> >
>>> > Although in that case, it apparently doesn't make difference on the end
>>> > result.
>>> >
>>> > I wouldn't be surprised that similar issues would appear elsewhere in the
>>> > code base.
>>> >
>>> > Even
>>> >
>>> > Le lundi 24 août 2015 05:16:50, vous avez écrit :
>>> >> 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
>>> >
>>> > --
>>> > Spatialys - Geospatial professional services
>>> > http://www.spatialys.com
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
More information about the gdal-dev
mailing list