Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#5438 closed defect (invalid)

GDAL ImageDriver of ENVI hdr

Reported by: kassol Owned by: warmerdam
Priority: normal Milestone: 1.10.2
Component: GDAL_Raster Version: 1.10.1
Severity: normal Keywords: hdr raster
Cc:

Description

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;

Attachments (1)

output.jpg (547.9 KB) - added by kassol 3 years ago.
the output image

Download all attachments as: .zip

Change History (6)

Changed 3 years ago by kassol

Attachment: output.jpg added

the output image

comment:1 Changed 3 years ago by Even Rouault

Milestone: 1.11.0
Priority: highnormal
Resolution: invalid
Severity: criticalnormal
Status: newclosed

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.

comment:2 in reply to:  1 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by kassol

Resolution: invalid
Status: closedreopened

comment:4 Changed 3 years ago by Even Rouault

Resolution: invalid
Status: reopenedclosed

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.

comment:5 Changed 3 years ago by Even Rouault

Milestone: 1.10.2

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()"

Note: See TracTickets for help on using tickets.