RGB channels for imagery

[jonblower]

It would be good to have a standard way of representing channels of satellite imagery, particularly RGB. This could be as simple as using defined URIs for observedProperties, or maybe it's a use case for ParameterGroups?

[letmaik]

Good idea, I think this is more a thing for observedProperties URIs, since for analysis of satellite images with multiple channels (may be > 3) you create false color combinations. I'm not sure if those combinations are strict concepts or more trial-and-error. Therefore defining parameter groups would be a bit arbitrary maybe, not sure.

For the three-channel-only case however, it could be as simple as recommending certain parameter key names: red, green, blue. The definite clue would still be the observed property URI.

[jonblower]

Yep, agree with this. Sensible parameter names plus definitive URIs. I don't know where these URIs would come from though. Also we might need to think about different ways of representing the pixel values (e.g. bytes in range 0-255, fractions in range 0-1, or something that is closer to the imaging instrument).

[letmaik]

Hmm, tricky. You could say that all pixel values are fractions in a way, with the 0-255 parameter having a unit of 1/255. On the other hand you can maybe regard 0-255 as some kind of normalized count of brightness or photons. I would probably go for the first option.

[letmaik]

Let's use Landsat as an example. It has slightly different wavelengths for blue (and others) in different satellites. (http://landsat.usgs.gov/best_spectral_bands_to_use.php) Also, the GeoTIFF files have values in 0-255 which, with embedded metadata (offset/factor and others), can be converted to spectral radiance in physical units.

This is how 0-255 could be represented in that case (minting observed property URIs obviously..):

{
  "type" : "Parameter",
  "observedProperty" : {
    "id": "http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/DN"
    "label" : {
      "en": "Spectral radiance as digital number in blue spectral band (0.45 - 0.51 µm)"
    },
    "narrowerThan": ["https://en.wikipedia.org/wiki/Blue", "http://qudt.org/vocab/quantity#DimensionlessRatio"]
  },
  "unit" : {
    "symbol": {
      "value": "1/255"
      "type": "http://www.opengis.net/def/uom/UCUM/"
    }
  }
}

They call the pixel values "digital number" (DN).

If you would store the actual spectral radiance, then it would look like:

{
  "type" : "Parameter",
  "observedProperty" : {
    "id": "http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/radiance"
    "label" : {
      "en": "Spectral radiance in blue spectral band (0.45 - 0.51 µm)"
    },
    "narrowerThan": ["https://en.wikipedia.org/wiki/Blue"]
  },
  "unit" : {
    "label": {
      "en": "Watt per steradian per square metre per micron"
    },
    "symbol": {
      "value": "W.sr−1.m−2.um−1"
      "type": "http://www.opengis.net/def/uom/UCUM/"
    }
  }
}

In both cases you would know that it is the blue band as a general concept due to "narrowerThan", and I couldn't find a better URI than https://en.wikipedia.org/wiki/Blue. For the 0-255 case, you would have to look for http://qudt.org/vocab/quantity#DimensionlessRatio and the 1/255 unit to display it correctly.

This example also shows that just having units doesn't mean that you can convert between things easily. If you wanted to convert from a DN parameter in 0-255 to the spectral radiance parameter, you could check if you know a conversion between http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/DN and http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/radiance in some knowledge base (yay...). Alternatively, common conversions could be embedded, however this seems not possible to have in general, as the conversion may be too complicated to describe in a simple JSON structure.

[jonblower]

When "true-colour" images are derived from satellite images, what is normally done? They must identify the RGB channels (or the closest equivalents), but how are the relative brightness of the channels calculated? (I guess that in some cases there may be more than 3 channels involved since several channels may hold "blue" information.)

[letmaik]

I think relative brightness means choosing a good white balance that is perceived "right" on human eyes, based on some known or approximated calibration, in professional photography typically by photographing a calibration sheet with a gray patch in the same lighting conditions. In satellite photography you probably don't have that luxury, so they probably use some heuristic or even a fixed white balance for day vs night.

So yeah... that means what I proposed about finding a conversion between http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/DN and http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/radiance would likely not work since each image or set of images may use different parameters for deriving the quantized brightness numbers. http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/DN as a URI could then not be used for the observed property of the 0-255 parameter, this would probably be the URI that goes into "narrowerThan" and the actual URI would be unknown since it would have to encode the specific parameterized conversion I think, which of course could exist as a URI (and which would be nice by the way), but in reality probably never will, at least in the near future.

[BillSwirrl]

Hope you don't mind me joining your github discussion! And apologies if I misunderstand the issue through not being involved in the discussion till now. Maik linked to this issue in the SDW call earlier.

Looking up those Landsat links, I see that there are typically many channels (many more than 3). What options do you get for retrieving those from 'official' data stores? Are they usually grouped into 3 and provided as geotiff images? or can you get a single channel or all 11 channels at once in some other format? Do they always have values between 0 and 255? And do they publish how the radiance is converted into the 0-255 scale? (I will RTFM at http://landsat.usgs.gov/Landsat_Processing_Details.php and try to answer my own questions!)

Anyway, seems like you do indeed have lots of different 'observed properties' and want a URI for each one - which could probably be directly associated with eg 'Landsat 8, Band 1', 'Landsat 8, Band 2' etc. Providing some documentation or metadata on what http://blah.com/def/landsat8/band1 refers to in terms of physical properties would be useful, but I don't see that you'd want to do that in general or automatically.

Your coverage file just provides a bunch of numbers, your observedProperty URI is an identifier for what the number represents, then you can attach as much information as you like to that property URI to document what it means (maybe using https://www.w3.org/TR/prov-o/ if you want to get fancy and detailed about the processing that has been done to get the associated values).

[BillSwirrl]

by the way, where is the best place to read about how different combinations of the measured bands are turned into things like land cover classifications?

[jonblower]

@BillSwirrl - yes the "RGB" example is a very simplified one, intended to get at the basics of encoding different wavelength bands. As you say, satellites typically have many more channels than this. If you have an RGB product with integer pixel values (0-255) you might have a highly derived product (true colour or false colour) for basic display, rather than the "real" satellite product. Although sometimes the "native" radiance values may be compressed into the 0-255 range with a scale and offset as Maik describes.

One question I have is - how do we indicate the wavelengths (or wavelength ranges) of the bands in a machine-readable way? Is this done in the document to which the observedProperty URI points? Or do we do this in the CovJSON document itself? I.e. is the observed property "radiance" (with other metadata recording the wavelength) or "radiance of wavelength X"? I guess some previous EO-related standards would have something to say about this, we should check them out.

(It's also worth noting that satellite products might record other things than radiance, like reflectance at a wavelength.)

where is the best place to read about how different combinations of the measured bands are turned into things like land cover classifications?

I'm not an EO expert, but one of my colleagues has pointed me towards https://www.ffpri.affrc.go.jp/redd-rdc/en/reference/cookbook.html. Algorithms range from simple arithmetic on wavelength bands at each pixel (e.g. NDVI) to highly complex algorithms that take a whole host of things into account, including previous measurements of the pixel.

[letmaik]

One question I have is - how do we indicate the wavelengths (or wavelength ranges) of the bands in a machine-readable way? Is this done in the document to which the observedProperty URI points? Or do we do this in the CovJSON document itself? I.e. is the observed property "radiance" (with other metadata recording the wavelength) or "radiance of wavelength X"?

I would say for actual radiance you could do this:

{
  "type" : "Parameter",
  "observedProperty" : {
    "id": "http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/radiance"
    "label" : {
      "en": "Spectral radiance in blue spectral band (0.45 - 0.51 µm)"
    },
    "wavelengthRange": {
      "start": 0.45,
      "end": 0.51,
      "unit": "http://qudt.org/vocab/unit/MicroM"
    },
    "narrowerThan": ["https://en.wikipedia.org/wiki/Radiance#Spectral_radiance", "https://en.wikipedia.org/wiki/Blue"]
  },
  "unit" : {
    "label": {
      "en": "Watt per steradian per square metre per micron"
    },
    "symbol": {
      "value": "W.sr−1.m−2.um−1"
      "type": "http://www.opengis.net/def/uom/UCUM/"
    }
  }
}

The more general concept https://en.wikipedia.org/wiki/Radiance#Spectral_radiance would go under "narrowerThan".

The "wavelengthRange" would be defined in the rdf document at http://landsat.usgs.gov/satellites/Landsat_8/instruments/OLI/bands/Blue/processing/radiance where the JSON version above is just the JSON-LD version of it. Of course, that assumes quite a lot, and in reality this probably won't work, since the structures may be quite different in their rdf. But, just saying, ideal world etc.

Not sure if https://en.wikipedia.org/wiki/Blue fits in here as narrowerThan, or if that is just something like "related".

[BillSwirrl]

@jonblower

is the observed property "radiance" (with other metadata recording the wavelength) or "radiance of wavelength X"?

We've been through similar thought processes in the context of statistical data in the RDF Data Cube vocabulary.

You see different styles taken by different people - all of them correct and workable, but not convenient that different people do different things - in the data cube approach, there are basically three things that you can spread your machine-readable semantics between: the measure property, dimension properties and attributes (here we're talking mainly about measurement units).

So if someone is talking about a temperature observation say, three possible (made up but representative) approaches might be:

measure: temperatureInKelvin

measure: temperature
unit: Kelvin

measure: obsValue (i.e. something totally generic)
dimension: quantityMeasured = temperature
unit: Kelvin

For our statistical work, we've tended to go for the middle approach in most cases. In government statistical data, that tends to lead to a fairly small number of different measures, and helps to make it possible to decide which different datasets you can meaningfully compare. But there's no single correct answer here.

by the way - thanks for that link to the REDD cookbook. Will take a look

[BillSwirrl]

@neothemachine on the topic of how to represent the characteristics of the sensors/bands, it's probably worth having a look at the Semantic Sensor Network (SSN) strand of Spatial Data on the Web activity. http://w3c.github.io/sdw/ssn/ (and also the original SSN ontology https://www.w3.org/2005/Incubator/ssn/ssnx/ssn) They are working on an ontology for sensors and sensor data, which may well be applicable. I'm not familiar with the details of what they've been doing but will have a look myself.

[letmaik]

Closing this as it's not a CovJSON issue but rather for guidance on using the right observed property URIs to identify the channels. As a standard, CovJSON should be focused on the core and delegate application-specific usage to the community. Given that there was no further interest in this I'll close this.