[gdal-dev] Confusion reading .img raster band.

[Robert Denham]

Actually I solved my problem by using a multidimensional array, which has
the advantage of being able to reference any pixel by scanline[row][col]. 

On another point, I have been having some difficulties working with img
files that have been created under windows. I am working on solaris
unix. If I open these img files under unix imageine and save them as
something else he problem disappears. Anyone have any suggestions as to
what migh be happening here?

------------------------------------
| Robert Denham |
| School of Mathematical Sciences |
| Queensland University of Technology |
| denham at f... |
------------------------------------

On Thu, 16 Nov 2000, Robert Denham wrote:

> Dear gdal-dev,
> I am a bit confused reading data from an ERDAS Imagine
> File. Using the tutorial as a guide I wrote a test program which just
> prints out the values of the image in col/row order, just like the imagine
> pixel->ascii function. Unfortunately it doesn't quite match up with the
> imagine equivalent, but seems to duplicate the final pixel in each line.
> 
> let me show you:
> The tree columns on the left are my results, the three on the right are
> imagine results.
> first line is fine, but the first value on the second line is the same as
> the last value on he line above, which puts everything out.
> 
> 
> 
> X Y val	X Y B1
> 0 0 75.705154	0 0 75.7051544189453
> 1 0 75.349915	1 0 75.3499145507812
> 2 0 74.681129	2 0 74.6811294555664
> 3 0 74.023941	3 0 74.0239410400391
> 4 0 73.616539	4 0 73.6165390014648
> 5 0 73.284485	5 0 73.2844848632812
> 6 0 73.174126	6 0 73.1741256713867
> 7 0 73.244751	7 0 73.2447509765625
> 8 0 73.160934	8 0 73.1609344482422
> 9 0 73.078377	9 0 73.0783767700195
> 10 0 72.998413	10 0 72.9984130859375
> 11 0 72.918442	11 0 72.9184417724609
> 12 0 72.667473	12 0 72.6674728393555
> 0 1 72.667473	0 1 75.8207702636719
> 1 1 75.820770	1 1 75.3696441650391
> 2 1 75.369644	2 1 74.8217010498047
> 3 1 74.821701	3 1 74.3044281005859
> 4 1 74.304428	4 1 73.9780883789062
> 5 1 73.978088	5 1 73.332878112793
> 6 1 73.332878	6 1 73.317741394043
> 7 1 73.317741	7 1 73.2660064697266
> 8 1 73.266006	8 1 73.2488327026367
> 9 1 73.248833	9 1 73.1332397460938
> 10 1 73.133240	10 1 73.0532760620117
> 11 1 73.053276	11 1 72.9733047485352
> 12 1 72.973305	12 1 72.7634429931641
> 0 2 72.973305	0 2 75.8491439819336
> 1 2 72.763443	1 2 75.3893661499023
> 
> etc.
> 
> Here is the relevant bit of code I used:
> hBand = GDALGetRasterBand (hDataset, 1);
> nXSize = GDALGetRasterBandXSize (hBand);
> nYSize = GDALGetRasterBandYSize (hBand);
> pafScanline = (float *) CPLMalloc (sizeof (float) * nXSize * nYSize);
> GDALRasterIO (hBand, GF_Read, 0, 0, nXSize, nYSize,
> pafScanline, nXSize, nYSize, GDT_Float32, 0, 0);
> 
> for(row=0;row<nYSize;row++) {
> for(col=0;col<nXSize;col++) {
> printf("%d %d %f\n",col,row, pafScanline[row*nYSize+col]);
> }
> }
> 
> This might be a simple programming error but I'm not too proud to have the
> obvious pointed out to me.
> 
> Thanks fro any suggestions,
> robert 
> 
> 
> ------------------------------------
> | Robert Denham |
> | School of Mathematical Sciences |
> | Queensland University of Technology |
> | denham at f... |
> ------------------------------------
> 
> 
> 
> 
> 
>