GDAL ImageDriver of ENVI hdr

[kassol]

Read an image in ENVI .hdr format that is in BIP band format with 3 bands and 17000 cols and 17000 rows to a buffer with three bands size.

using the GDALRasterBand::RasterIO function.

like the code below,the output image is wrong

GDALDataset* pDataset = (GDALDataset*)GDALOpen("D:\\all3_cut.img", GA_ReadOnly);
int nBands = 0, nXSize = 0, nYSize = 0;
nXSize = 5000;
nYSize = 5000;
nBands = pDataset->GetRasterCount();
const double times = 0.15467;
int nCols = int(nXSize*times);
int nRows = int(nYSize*times);
unsigned char* p = new unsigned char[nCols*nRows*nBands];
memset(p, 0, nCols*nRows*nBands);
int bandmap[] = {1, 2, 3};
CPLErr er = pDataset->RasterIO(GF_Read, 0, 2000, nXSize, nYSize,
	p, nCols, nRows, GDT_Byte, nBands, bandmap,
	nBands, nCols*nBands, 1);

GDALClose((GDALDatasetH)pDataset);
GDALDriver *poDriver;
poDriver = GetGDALDriverManager()->GetDriverByName("GTIFF");
pDataset = poDriver->Create("C:\\all3_cut.tif", nCols, nRows, nBands,
	GDT_Byte, NULL);
CPLErr err = pDataset->RasterIO(GF_Write, 0, 0, nCols, nRows,
 	p, nCols, nRows, GDT_Byte, nBands, bandmap,
 	nBands, nCols*nBands, 1);

GDALClose((GDALDatasetH)pDataset);
delete []p;
p = NULL;

[kassol]

the output image

[Even Rouault]

Your computation of the nLineOffset in the read RasterIO is incorrect. It should be nXSize*nBands.

And to make your life easier, you could juset the nPixelOffset, nLineOffset and nBandOffset values to 0 and let GDAL figure that out for you.

[kassol]

Replying to rouault:

Your computation of the nLineOffset in the read RasterIO is incorrect. It should be nXSize*nBands.

And to make your life easier, you could juset the nPixelOffset, nLineOffset and nBandOffset values to 0 and let GDAL figure that out for you.

What I want to read is subsample data, from nXSize*nYSize*nBands to nCols*nRows*nBands.

Should I set the nLineOffset to nXSize*nBands but not nCols*nBands?

And what exactly the nLineOffset is based on ? Image or Buffer? According to the wiki ,I think it is based on the buffer.The code I pasted above is to make it easier to figure out the question. What I was doing is that

pDataset->GetRasterBand(1)->RasterIO(GF_Read, 0, 2000, nXSize, nYSize,
 	p+(nRows-1)*nCols*nBands, nCols, nRows, GDT_Byte, nBands,
 	-nBands*nCols);

to read the data from top->bottom to bottom->top.

And eventually they work the same result, the arrangement of pixels is not right.like the output image.

[Even Rouault]

I don't think this is a bug in GDAL, but in the way you use it (if gdal_translate works with your data, this will be clearly the case). Tickets are not meant for user assistance. Please use gdal-dev mailing list instead.

[Even Rouault]

Sorry for dismissing your report, you were right: there was indeed a bug. And my first comment was also wrong: the nLineOffset was correct. Your mention in IRC about the DirectIO() code path was critical to understand there was indeed an issue, since that optimized code path is taken far less frequently than the generic RasterIO() (and it appeared to not being triggered in our regression tests), the latter should be pretty much bug-free since it is heavily used...

Anyway, here it is :

trunk r27192, branches/1.10 r27193 "RawRasterBand: fix optimized RasterIO() when doing sub-sampling with non standard buffer pixel offset (#5438)"

trunk r27193 "RawRasterBand: a bit of cleanup and potential better handling of 64bit offsets in IRasterIO()"