support bad band metadata stored at band level

[Andreas Rabe]

As described in the Glossary, we want to support bad band specification at band-level:
https://enmap-box.readthedocs.io/en/latest/general/glossary.html#term-bad-band-multiplier

‌

‌

The GDAL metadata isn’t concidering this correctly:

‌

‌

[Benjamin Jakimow]

to be discussed, see comments #1088

[Benjamin Jakimow]

Probably already solved by extending the lookup patterns.
Please re-test. If possible, provide a unit test that starts opens the layer properties for the data you mean.

[Andreas Rabe]

Find a snippet here: QGISPlugIns/enmap-box/snippets/issues/issue1089.py

‌

from osgeo import gdal

from enmapbox import EnMAPBox, initAll
from enmapbox.exampledata import enmap
from enmapbox.testing import start_app
from enmapboxprocessing.rasterwriter import RasterWriter
from qgis._core import QgsRasterLayer

# create raster with a bad band
filename = 'enmap.vrt'
ds = gdal.Translate(filename, enmap)
writer = RasterWriter(ds)
writer.setBadBandMultiplier(0, 2)
del writer, ds
layer = QgsRasterLayer(filename)

qgsApp = start_app()
initAll()
enmapBox = EnMAPBox(None)
enmapBox.onDataDropped([layer])
qgsApp.exec_()

‌

It’s not fully clear, what the meaning of “False” is in your dialog, but I guess the bad band (i.e. the second band) should show True, and all other bands False. In that regard, it is still not working:

‌

[Agustin Lobo]

Note the bbl in the ENVI hdr follows the opposite convention: 1 for correct bands, 0 for bad bands:

“Lists the bad band multiplier values of each band in an image, typically 0 for bad bands and 1 for good bands.”

https://www.l3harrisgeospatial.com/docs/enviheaderfiles.html

[Andreas Rabe]

Yes, turning a 1 into False is a bit misleading.

[Benjamin Jakimow]

@Andreas Janz thx for fixing the RasterWriter.setBadBandMultiplier bug. I was wondering why only band 2 is set to False

[Andreas Rabe]

Note that I will use “bbl” as key for bad band multiplier (see #1095).

[Benjamin Jakimow]

resolves #1089

→ <<cset f005732a2ddd>>