Take hdr field "bbl" (bad bands list) into account

[Agustin Lobo]

Apparently, EnMapBox ignores the bbl (bad bands list) field.

Could it be taken into account both for extracting spectra and for processing (classification)?

[Benjamin Jakimow]

I could add this as an option for the selection of spectral profiles from map canvases and the import of spectral profile from ENVI binary files. In that case band with the BBL flag are excluded from the spectral profile vectors.

However, I don’t like solutions that focus on a single file format only. In case of further processing routines it would mean to check each image input for the BBL flags - something that is unknown in the GDAL concept of representing raster bands. Instead it might be worth to have a processing algorithm that returns the valid bands only, e.g. als VRT image that serves as input to other processing algorithms. Any suggestions @Andreas Janz ?

‌

[Agustin Lobo]

The VRT trick is a way of circumventing the problem, but the format issue will always be there. In my opinion, no current GDAL format is appropriate for hyperspectral imagery: this is why the very ancient hdr is still being the most used. I suggest EnMapBox enforcing to create an hdr companion file for any format. I know xml is more fashion, but I do not really see the point of substituting something that is simple, popular and… works. But programmers might have a different view. In case you favor having a companion hdr-like file in xml format, please provide a tool to translate hdr ↔︎ xml

‌

[Benjamin Jakimow]

Otherwise the VRT trick allows you to use your none-bad-bands with other algorithms from the QGIS processing framework. This way you could define processing chains with algorithms from EnMAP-Box, GRASS, GDAL, SAGA etc. That's mainly the reason why we try to avoid solutions that focus on a single file format.

Personally I prefer to store metadata using the GDAL metadata model:

• it allows to set metadata values for the entire data sets and for each single bands. For example you could define a different classification scheme for each band
• it provides a domain / “name-space” concept.
• its metadata entries can be accesses via the GDAL API in a consistent way. You do not need an extra ENVI header file parser
• meta data entries are stored in the *.aux.xml files, which can be modified easily in any state-of-the-art programming language or text editor (a JSON format instead would be great as well)

However, it’s an ongoing discussion in our team and very helpful to get your feedback @Agustin Lobo, because this shows us typical problems and use-cases.

‌

[Agustin Lobo]

I do trust you on the *.aux.xml solution being better than the hdr file, but please provide a tool for the automatic conversion of hdr to and from the aux.xml file. Having to do it file by file with a text editor is not an option.

[Benjamin Jakimow]

Do you need the BBL afterwards or would it be ok to just mask these bands out and proceed with a reduced number of bands?

[Agustin Lobo]

In my current problem, I just can neglect bands in the bbl for ever so I have made a version in which they are just not present. Therefore, it is not an urgent problem for me. But in general, the reason for having a bbl field in the hdr file is to avoid having to keep copies of the images. So it would be nice having EnMapBox algorithms ignoring those in a bbl field (perhaps through a temporal VRT file as you said).

[Andreas Janz]

I will include a corresponding checkbox “Exclude bands from ENVI Bad Bands List (BBL)” in the Subset Raster Bands processing algo:

‌

[Andreas Janz]

Done

‌