I'm trying to transfer a subset (box (0,0)-(300,300)) of a panchromatic geotiff to a new file. Although the georeference and the set are transferring correctly, the raster values seem off.

Loading the raster files in qGIS give me at the original .tif values 7614-15959 and at the resulting .tif 0-14530.

Just to clarify: I have no other problems (with projection, georeference or the crop result's borders).

(datasets are GDALDataset and bands are GDALRasterBand)

/*GET PANCHROMATIC BAND*/ band_pan = dataset_pan->GetRasterBand(1); /*GET IMAGE/BAND DATATYPE*/ bufDataType=band_pan->GetRasterDataType(); /*CREATE NEW IMAGE WITH SAME DATATYPE*/ char **cropOptions = NULL; dataset_crop = poDriver->Create(fname_crop,512,512,1,bufDataType,cropOptions); /*TRANSFER GEOREFERENCE INFO*/ double adfGeoTransform[6]; dataset_pan->GetGeoTransform( adfGeoTransform ) dataset_crop->SetGeoTransform(adfGeoTransform); dataset_crop->SetProjection( dataset_pan->GetProjectionRef() ) /*READ IMAGE SUBSET*/ band_pan->RasterIO(GF_Read,0,0,300,300,buffer,bufsizeX,bufsizeY,bufDataType,0,0); /*GET NEW IMAGE'S BAND*/ band_out = dataset_crop->GetRasterBand(1); /*WRITE SUBSET ON NEW IMAGE*/ band_out->RasterIO(GF_Write,0,0,300,300,buffer,bufsizeX,bufsizeY,bufDataType,0,0);

Am I missing something?

  • I need to work with a buffer, so using gdal_translate I guess is out of the question (or is it?). – AlphaTester Oct 16 '15 at 19:44
  • A hunch: since you're copying pixels from a 300px square to a 512px square, some of the target pixels will be empty, possibly giving you the zero lower limit in the target. And since you presumably have valued pixels in the source that you're not copying, the source might have a higher upper limit. In other words, you're copying pixels with values in the range 7614-14530 from a raster with range 7614-15959 into a zero grid, creating a new range: 0-14530. Possible? – Rob Skelly Oct 16 '15 at 22:05
  • Have you run gdalinfo on both files? Was there scaling or offset on the input? – BradHards Oct 17 '15 at 2:00
  • @RobSkelly good point! I didn't specify that most pixels (not all though) change value even though their original values are included on both ranges. that's why I guessed that it's a range problem. However, you inspired me to change the output file size & crop size. When both the output AND the crop box have same size as the original image, the result was a clone. Same when transferring all parts of the original file (I used RasterIO several times). – AlphaTester Oct 17 '15 at 11:53

After trial & error, using help from @RobSkelly @BradHards, the problem seems to have been the bufsize I used at the RasteRIO, which should have been the SAME as the crop-box size.

The function was scaling some pixels in order to fit the cropsize in the bufsize resulting in changes in values.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.