[gdal-dev] Hacking the new Landsat pixel_qa help...

Blumentrath, Stefan Stefan.Blumentrath at nina.no
Fri May 5 09:17:18 PDT 2017


If you don't mind some advertising of own work, have a look at:

If you want to do this using gdal,  the python code might be a source of inspiration... 

Von: gdal-dev [gdal-dev-bounces at lists.osgeo.org] im Auftrag von Rutger [kassies at gmail.com]
Gesendet: Freitag, 5. Mai 2017 10:37
An: gdal-dev at lists.osgeo.org
Betreff: Re: [gdal-dev] Hacking the new Landsat pixel_qa help...

Jonathan Greenberg-4 wrote
> Folks:
> USGS, in their infinite wisdom, decided to embed what is effectively a
> 1-bit, 16-band byte-interleaved-by-pixel image into a 16-bit, single-band
> geotiff for the Landsat quality mask.  I could write some crazy
> translation
> program that "reverse engineers" the data, but I was wondering if there is
> some way to "hack" or translate the file by simply redefining the "header"
> (change the number type to 1-bit, number of layers to 16, interleave to
> BIP).  Any suggestions for how to do this?

Hey Jonathan,

I personally think storing it in a single band is not that bad, because you
can use bitwise operations to test many flags in a single operation, which
is very efficient.

The new Python VRT pixel functions, which are available in 2.2 should be
able to do this. I haven't had a change to test it. But creating a VRT
calling some sort of 'bitcheck' function can be specified with a different
bit to check for each band.

Modifying the example from the VRT tutorial on gdal.org, it might look
something like this (completely untested):

<VRTDataset rasterXSize="20" rasterYSize="20">
  <VRTRasterBand dataType="Byte" band="1" subClass="VRTDerivedRasterBand">
    <PixelFunctionArguments check_bit="5"/>

For multiple output bands it would be better to store the function in a
separate file somewhere, instead of repeating the code for each derived

Since Landsat also combines bits (for the low/med/high ones), the function
would need to be changed a little, this is just to get an idea.

I'm not convinced this is more better/preferable than doing the bit-checking
at the point where you would do something else with the data. Although maybe
for 'direct' visualization in QGIS for example it might be nice.

The new VRT pixel functions open up a lot of possibilities, especially in
combination with Numba, its exciting to see where this is heading.


View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Hacking-the-new-Landsat-pixel-qa-help-tp5319426p5319456.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
gdal-dev mailing list
gdal-dev at lists.osgeo.org

More information about the gdal-dev mailing list