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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mateusz Loskot
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
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Implementing driver to support-of output format

Even Rouault-2

On dimanche 5 mars 2017 22:47:54 CET Mateusz Loskot wrote:

> 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?

 

Hi Mateusz,

 

if you look at apps/gdal_translate_lib.cpp, you'll see that, except cases without any arguments like gdal_translate in out -of output_format where the 'in' dataset is passed as the source dataset of CretaeCopy(), as soon as you add some transformation like changing data type, subsetting, etc, a in-memory VRT will be created to do that transformation. And it is that in-memory VRT that is passed as the source dataset to the CreateCopy() implementation of the output driver. That should answer all your following questions.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Implementing driver to support-of output format

Mateusz Loskot
On 5 March 2017 at 22:54, Even Rouault <[hidden email]> wrote:

> On dimanche 5 mars 2017 22:47:54 CET Mateusz Loskot wrote:
>>
>> Which, if any, part is responsible for the magic that changes the
>> pixel data form Byte to Uint16 during the RasterIO?
>
> Hi Mateusz,
>
> if you look at apps/gdal_translate_lib.cpp, you'll see that, except cases
> without any arguments like gdal_translate in out -of output_format where the
> 'in' dataset is passed as the source dataset of CretaeCopy(), as soon as you
> add some transformation like changing data type, subsetting, etc, a
> in-memory VRT will be created to do that transformation. And it is that
> in-memory VRT that is passed as the source dataset to the CreateCopy()
> implementation of the output driver. That should answer all your following
> questions.

Hi Even,

Right, I looked there and noticed the use of VRT, but its purpose wasn't clear
(or I didn't look deep enough).
Yes, that answers my question, thank you.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Loading...