gdalbuildvrt does not propogate Offset or Scale

[thare]

Maybe this is by design, but currently when running gdalbuildvrt, it does not propagate the Offset or Scale parameters from images that have it defined. I will report this as a minor issue.

Fortunately if the VRT is manually edited to add these back in, they do propagate these back into the image format:

specific keywords not propagated into the VRT <Offset>0.0</Offset> <Scale>1.0</Scale>

Regards, Trent

attached is an image (ISIS3 cub) with Offset and Scale keywords. Also a created vrt using gddalbuildvrt and a manually edited vrt to add back in the keywords.

[thare]

ISIS3 raster example with created vrt and manual vrt with offset and scale

[Even Rouault]

Trent,

As scale and offset are a relatively rarely used feature by GDAL drivers, this point isn't addressed at all currently.

It is a bit difficult for me to generalize a solution from a use case that just implies one image to put in the VRT.

First thing, if you just need to produce a VRT with a single source, "gdal_translate -of VRT your.source dest.vrt" is probably the best approach as it will try to copy all the various attributes of the source band (scale, offset, metadata, etc...).

Otherwise, if you really need to produce a mosaic of datasets that have scale and offset values, I see 2 possibilities :

• the one you choose in your manual VRT (or that is used by gdal_translate -of VRT), that is to say to put the scale and offset value at the VRT raster band level. This works OK when you have just one source, or several sources with identical scale and offsets. But of course, this cannot work when the sources have different offset/scale values. This solution also means that the client app must handle offset and scale itself.
• the other one would be to put them at the source level. It seems that it is handled by the ComplexSource object rather than the SimpleSource one. The ComplexSource will do the offset and scaling for the client app which won't be aware of them (the offset and scale at the ComplexSource level are not exposed at the band level). This approach can work when putting datasets with different values of offset and scale in the VRT.

I'd tend to prefer the second approach. Any thought ?

[warmerdam]

In my opinion, gdalbuildvrt should not default to creating a ComplexSource that applies offset/scale to actually rescale the data as this is dissimilar to how everything else is handled though there could be a commandline switch to request this.

gdalbuildvrt *could* attempt to copy the offset/scale values from the first image as band level metadata, and then confirm that all the other files have the same offset/scale values. However, given the rarity of these values being used and the number of other similiar things that could be handled similarly (metadata, palette, RAT, description, etc) it is not clear that we want to head down this path.

[Even Rouault]

Untargetting. No action will be taken for now.

[Even Rouault]

In 41749:

gdalbuildvrt: add support for band scale and offset (fixes #3221)