Provide a TensorBoard-native summary writer API

[nfelt]

This issue tracks work to provide, within TensorBoard proper, a summary "writer" API for end-users to log data for visualization in TensorBoard. This is intended to be a lightweight way to log to TensorBoard without necessarily depending on TensorFlow, although it should also be usable by eager-mode TensorFlow users.

Note that this API isn't intended to replace tf.summary - the latter will continue to be the recommended approach for TensorFlow users who want to log data from within graphs or tf.functions.

Plan of work. Some of these steps may be done on-demand / as need arises.

• Define initial Writer object and Output interface with scalar support
• Port tf.summary summary types
  • Scalars
  • Images
  • Audio
  • Histograms
  • Text
  • HParams
  • Graph
  • PR curves
  • Custom scalars
  • Mesh
  • Embedding
  • NPMI
• Add support for generic / extensible summary types
• Add support for tracking a step within the writer itself
• Add Output mechanism for logging the version of TensorBoard used to write data
• Implement other Output types
  • In-memory output
  • Logging to stdout
• Implement filesystem support for DirectoryOutput
  • Local filesystem
  • tf.io.gfile support
  • GCS support (without TF)
• Add API documentation
• Add demo (or retrofit existing demos)

[jpauwels]

Isn't this what TensorboardX is trying to do as well? Might be more efficient if both efforts could be joined (if that works out licence-wise).

[nfelt]

Thanks for asking. It's a bit of a long story, but basically we are aware of TensorboardX and have collaborated in the past, and some of the code in the repo today was contributed by the author of TensorboardX - see #2065 for example. The work described in this issue will be building on that foundation and essentially "closing the loop" relative to the initial foray in this direction from a few years ago.

The main motivation here is that we would like to provide a "standard" first-party API from TensorBoard itself. This makes it possible to use TensorBoard in a self-contained way, and lets us provide first-party demos, tutorials, possibly UI messages, etc. that rely on this functionality being present and stable. Keeping this all in sync and aligning it with the long-term direction of the project is easier when it's code that we can maintain ourselves. I expect that TensorboardX on the other hand is likely happier being able to chart their own course; if we were to adopt the effort directly, besides licensing questions we're also subject to constraints in terms of code style, backwards compatibility, dependencies etc. that we are used to but they might find limiting.

So while I agree there's some overlap and possible opportunity to converge in the long-term, I believe for now it's simpler to allow these efforts to evolve independently.