[gdal-dev] Implementing driver to support-of output format

Mateusz Loskot mateusz at loskot.net
Sun Mar 5 13:47:54 PST 2017


Hi,

I have a question about "-of output format" handling in a raster
driver implementation:

1. src_byte.tif is single band of Byte data type.

2. gdal_translate -of GTiff -ot UInt16 src_byte.tif dst_uint16.tif

3. In an implementation of `CreateCopy`

CreateCopy(char const* pszFilename, GDALDataset* poSrcDS, int bStrict, ...)
{
    ...
    eDT = poSrcDS->GetRasterBand(1)->GetRasterDataType();
    ...
    poSrcDS->RasterIO(GF_Read, ..., eDT, ...);
    ...
}

a) The source dataset band type is UInt16, while band in the source
src_byte.tif file is Byte.
b) RasterIO requests Uint16 from the src_byte.tif with Byte band.

Which, if any, part is responsible for the magic that changes the
pixel data form Byte to Uint16 during the RasterIO?

The driver tutorial
http://gdal.org/gdal_drivertut.html#gdal_drivertut_creation only seems
to explain what happens
after RasterIO, that is the "transforming data types on the fly"
before writing the data it into destination dataset.

>From a driver's implementor point, I found that use case a bit puzzling.
I have not implemented raster driver yet and I'm lacking of knowledge
of handling advanced data transformations.

I always thought that reading from `poSrcDS` is always based on the
original data type, ie. Byte in my example.
Then, the destination dataset driver takes the byte stream and, if
capable, transforms the data type according to the requested output
data type (option -ot).

Could anyone enlighten me about how a destination driver XXX is
supposed to handle use cases like: gdal_translate -of XXX -ot UInt16
src_byte.tif dst_uint16.XXX?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net


More information about the gdal-dev mailing list