Proposal
Introduce an "agnostic" logger, that uses composition to encapsulate one of a series of possible torch lightning loggers (e.g MLFlowLogger, TensorBoardLogger .. )
Motivation and description
Currently, the code of SegmentationLightningModule relies on tensorboard to log non-numerical values such as images. Since LightningModule.log() only supports scalar artifacts, to log anything else one must rely on the underlying LightningModule.logger.experiment (docs), and the experiment object has different function signatures depending on the logger used, it would be good to hide the logger-specific details into a class that exposes a common set of functionalities, such as log_image(..).
Proposed solution
In my opinion, the agnostic logger should not extend lightning.pytorch.loggers.logger.Logger, like MLFlowLogger and TensorBoardLogger, but rather be a new object that encapsulates one of the existing loggers. Therefore, the SegmentationLightningModule will have two attributes to log: SegmentationLightningModule.logger,
set by the trainer and used by LightningModule.log() and SegmentationLightningModule.agnostic_logger, used to log non-scalar values which relies on the underlying logger but hides the overhead of dealing with different function's signatures.
I appreciate any feedback on this suggestion. I am willing to contribute and proceed with a draft pull request after the review of this issue.
Proposal
Introduce an "agnostic" logger, that uses composition to encapsulate one of a series of possible torch lightning loggers (e.g MLFlowLogger, TensorBoardLogger .. )
Motivation and description
Currently, the code of
SegmentationLightningModulerelies on tensorboard to log non-numerical values such as images. SinceLightningModule.log()only supports scalar artifacts, to log anything else one must rely on the underlyingLightningModule.logger.experiment(docs), and theexperimentobject has different function signatures depending on the logger used, it would be good to hide the logger-specific details into a class that exposes a common set of functionalities, such aslog_image(..).Proposed solution
In my opinion, the agnostic logger should not extend
lightning.pytorch.loggers.logger.Logger, likeMLFlowLoggerandTensorBoardLogger, but rather be a new object that encapsulates one of the existing loggers. Therefore, theSegmentationLightningModulewill have two attributes to log:SegmentationLightningModule.logger,set by the trainer and used by
LightningModule.log()andSegmentationLightningModule.agnostic_logger, used to log non-scalar values which relies on the underlying logger but hides the overhead of dealing with different function's signatures.I appreciate any feedback on this suggestion. I am willing to contribute and proceed with a draft pull request after the review of this issue.