Add `presentation` Extension

[jacobagilbert]

This extension was written to support suggestive input as to how SigMF Recordings and Metadata should be presented visually to users. A basic example of how this could be used is here: ~https://github.com/miek/inspectrum/pull/195~ https://github.com/miek/inspectrum/pull/208 which is just a quick proof of concept for how this might look.

There is no expectation that applications support all features of this, and the "simple" usage where an optional presentation:color field is added to annotations allows for the features in the above link. A much more descriptive set of features, presentation_style objects, are available that can be used to describe recommended presentation of entire classes of annotations or captures segments without requiring individual specification.

I believe this should be in-tree so as to make these field names common across applications and encourage adoption and convention.

The current implementation is blocked by #146 but this can be changed to work without it.

[bhilburn]

I'm in favor of this, and looks good. I'd say get it going, but deprecate your version to something < v1.0.0. Get feedback from @miek and others and target a v1.0.0 release with next SigMF minor release.

[gmabey]

That would be duplicate information, no? (Having alpha in 2 places)

Also, a separate alpha field has a very natural default value of 1.

On Mon, Apr 11, 2022 at 12:15 PM Jacob Gilbert @.***> wrote:

@.**** commented on this pull request.

In extensions/presentation.sigmf-ext.md https://github.com/gnuradio/SigMF/pull/234#discussion_r847609501:

+application using this extension is not required to implement any particular +feature. It is RECOMMENDED that applications adhering to the presentation +extension use default values in this document. It is also RECOMMENDED that +applications implementing this extension describe what fields are implemented.

+## 0 Datatypes + +The presentation extension defines the following SigMF datatypes: + +|type|long-form name|description| +|----|--------------|-----------| +|color|Hexadecimal Color String|String representing a 24 bit color (with optional alpha value) in hexadecimal form; either "#RRGGBB" or "#AARRGGBB".| + +### 0.1 The color datatype + +The color datatype is a string which MUST be either 6 or 8 hexadecimal

human readability is a strongly beneficial reason to do this. Not sold on separate alpha but i see your use case...will think more. could be an optional that overrides AARRGGBB....

— Reply to this email directly, view it on GitHub https://github.com/gnuradio/SigMF/pull/234#discussion_r847609501, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVTOUBC5DRHR3MPGZPAYJTVERT3DANCNFSM5ROCJGIQ . You are receiving this because you commented.Message ID: @.***>

[miek]

I've thought about this a bunch and, while I really like the idea of being able to encode some visual information, I worry that this implementation will lead to people creating recordings that only work well with their favourite tool/theme/colour-map. For example, I plan to add options for other colour maps to inspectrum at some point and presentation parameters for annotations created now could be unreadable on other colour maps.

I'd much rather see some way to encode intent rather than specific colours/styles, and then visualisation tools can interpret that in a way that works with their theme. Perhaps the naming scheme from standard logging levels could work, with fatal/error/warn/info/etc.? There could also be a way to define extra named groups, to group similar packets together for example.