[gdal-dev] Extending GDAL Color Interpretation enumeration for infra-red bands (+ band wavelength) ?
Daniel Evans
daniel.fred.evans at gmail.com
Sat Aug 31 11:54:24 PDT 2024
Hi Even,
Firstly, I'll state my bias as someone involved in the production of
thermal MWIR EO data (3.5-5um) - unsurprisingly, I'd like some
classification that fits my data :-)
> classifications...
The NIR - SWIR - MWIR - LWIR classification scheme is by far the most
common I've encountered in earth observation. I've never encountered the
CIE scheme or the ISO 20473 scheme in EO - the ISO definition of Mid(wave)
Infrared extending all the way out to 30um is definitely not typical usage.
Thermal Infrared (TIR) can be used as a blanket term for MWIR and LWIR. I
don't know if GDAL users would find it useful to split the two, or just
have a broad TIR classification; MWIR data products are still relatively
rare.
I'm not immediately aware of any commonly used Far Infrared (>15um) EO data
products.
On the two Github links you shared, some thoughts are:
- Both lack any entry covering the MWIR (~3-5um)
- The "Thermal" definition on the second link is LWIR only, not the more
normal MWIR+LWIR definition
- The second link in particular is heavily aimed at describing Sentinel and
Landsat - not unfair, given that they are the most widely used IR datasets!
However, the subclassifications in the second link - "NIR", "NIR 2", "SWIR
1", "SWIR 2", "Thermal 1", "Thermal 2" - are not generic terms in my
experience. The terms in the first link (swir16, swir22, lwir11, lwir12)
are more familiar if GDAL were to go to that level of detail, but I think
you'd still need generic "swir"/"lwir" names to cover data that don't match
the Sentinel/Landsat ecosystem.
> FWHM and Central Wavelength
I think this is the most sensible description of a band.
I would be in favour of your suggestion of making them generic across all
bands via the IMAGERY metadata, not just IR. The increasing number of
multispectral/hyperspectral EO missions mean that simple RGB
classifications for optical data without further description are not always
appropriate. The stac-extensions repo already shows the addition of extra
terms like "coastal", "green05", and "yellow" to further define optical
bands.
No strong opinions personally on whether that wider definition uses nm or
um for the unit, but perhaps others have a strong opinion on "red" being
"650nm" vs. "0.65um"?
Cheers,
Daniel
On Sat, 31 Aug 2024 at 15:22, Even Rouault via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:
> Hi,
>
> The GDAL Color Interpretation enumeration is a good start, but is quite
> limited regarding band spectral properties with just Red, Green, Bland,
> and nothing for other band wavelengths, particularly for infra-red.
>
> I was looking a bit at the classifications at
> https://en.wikipedia.org/wiki/Infrared#Regions , and there are several
> ones, like the "commonly used subdivision scheme" (NIR, SWIR, MWIR,
> LWIR, FIR) or "CIE division scheme" (IR-A, IR-B, IR-C) or "ISO 20743
> scheme" (NIR, MIR, FIR).
>
> My inclination would rather to re-use the STAC EO classification at
> https://github.com/stac-extensions/eo?tab=readme-ov-file#common-band-names,
>
> which shows a lot of similarities with
>
> https://github.com/awesome-spectral-indices/awesome-spectral-indices#expressions
> , and has a nice mapping with a few popular instruments.
>
> While we are it, should we standardize central wavelength and full width
> half max (FWHM), has special properties of a bands rather than generic
> text-based metadata, like:
>
> double GDALRasterBand::GetCentralWaveLengthMicrometer() -> NaN if unknown
> double GDALRasterBand::GetFWHMMicrometer() -> NaN if unknown
> void GDALRasterBand::SetCentralWaveLengthMicrometer(double)
> void GDALRasterBand::SetFWHMMicrometer(double)
>
> Or maybe just standardize a "CENTRAL_WAVELENGTH" and "FWHM" metadata
> items in the "IMAGERY" metadata domain:
>
> https://gdal.org/en/latest/user/raster_data_model.html#imagery-domain-remote-sensing
> ?
>
> Thoughts?
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240831/11ccb4ff/attachment.htm>
More information about the gdal-dev
mailing list