ok, so based on all feedback, I guess we could add GCI_PanBand,
GCI_CoastalBand, GCI_RedEdgeBand, GCI_NIRBand, GCI_SWIRBand,
GCI_MWIRBand, GCI_LWIRBand, + maybe GCIThermalRBand (that one with
overlap with MWIR and LWIR), without loosing too much generality + maybe
GCI_OtherIRBand for whatever other uses ? I realize we already have a
GCI_YellowBand, although it is thought for the CMYK color space. Do we
need a GCI_YellowSpectralBand enumeration value... ?
The documented associated wavelengths range for those constants could be
the ones of
https://github.com/stac-extensions/eo?tab=readme-ov-file#common-band-names
but with a warning that they are indicative only, and some sensors could
partially intersect the range, and that the wavelength metadata when
present has precedence.
In Pix4D, for the radiometric correction needed in the images, we
defined this XMP namespace years ago:
http://pix4d.com/camera/1.0/
There are "Xmp.Camera.CentralWavelength", "Xmp.Camera.WavelengthFWHM"
and "Xmp.Camera.BandName". I do not mean that we should do the same,
but just an example of how that information was important.
One question. The IMAGERY metadata is available only on TIF, or also
in other file formats like JPG? I mean without any sidecar.
This is per-se generic, but in practice, only the TIFF driver currently
fills it from the sidecar files of various metadata producers
(DigitalGlobe, Pleiades, etc.). It could also be stored in the GDAL
.aux.xml side car file for any PAM capable driver (the STACIT driver
could use the STAC eo metadata to also set the new GCI_ constant and the
wavelength metadata items, when present). The Sentinel2 driver also
could fill that. As well as the ENVI one when the metadata items are
present.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
