Change detection model works well for binary change detection on simple case like building class or tree. However, when we want to apply it to more complexe case like multiclass changedetection. In the 2020 paper Multitask Learning for Large-scale Semantic Change Detection (https://arxiv.org/abs/1810.08452), they use a semantic segmentation model to bring better representation of each class for multi class change detection.
The goad here is to build a pyotrch lightning to fit the goal of the associated milestone.

Some constant were accidentally introduced from another base code. Needs to be removed to avoid confusion.

PITCH:

in Odeon, we have created an Env singleton object, configured with a yaml file (env.yaml), instanciated during the bootstrap (see ENV).

In this object, we have dependencies to organization objects (Project, Team, User etc.). So, you actually can define some parameters like email or teams id.
The main concept of this plugin /Api is to bring the ability to a user to send email or teams message in a webhook to communicate events (in odeon fit, could be used to declare start or end of training, some result reached, etc).

TODO:

The need is to develop an Api in an internal plugin (named collab or whatever the developper wants to call it).
The plugin has to be placed at the root of the Odeon package (next to data, models and so on).
You need to declare a python Protocol as interface. This Protocol should at least have to declare a function like send(), with parameters, and LSP compliance for signature overriding (*args, **kwargs).

from typing import Protocols

class CollabProtocol(Protocols):
    def send(some_param, *args, **kwargs):
        ...
    ...

The Mail Collaborativ Class, the Teams collaborative class should respect that protocol, but not inherit from it (contract).

After implementation, we need to have a Dynamic Registry for pluginification and for extensibility, meaning ability to add other collaborative Api in an external plugin. (the data registry to register data module is an example, see DATA REGISTRY)
And we need to create an instance of OdnPlugin to register dynamically in respect with Odeon philosophy (eat your own dog food). We can take example of the plugins instanciated in the data package ( see DATA PLUGIN)
Final, stage add the plugin in the default plugin constant( see DEFAULT PLUGIN)
Write some simple unit tests for non API regression check for the next CI/CD packaging pipeline.

CAVEAT:

we will maybe need some external library for Teams (but maybe not as weebhooks are pure http protocols). If it's the case, these libraries will be optional libraries, meaning we need to check if they are in the python environment to register the concerned APIs.

BRANCH:

the branch to use and where to make the PR is the dev branch

file added in a commit by mistake in: v0.5.0 fix mypy error core/init

Pitch:

Odeon must be able to integrate any type of input data (modality agnostic), with potentially different read/write engines. All this while presenting a simple Api that hides the complexity. This is the role of the Layers Api.
To be able to do that, we need to refactor the code from layers, with implicit changes to the data internal plugin.

We need today, at least a DataHandler class to interface layers with the dataframe, a LayerCollection class to handle multiple layers in a duck typing way, and to start by making an Raster Layer and a Mask Layer.

If Input is picked as DataModule for the FIt App, we need to make sure that the Configuration system handles the augmentation instacations with the helper odeon.data.core.transform.build_transform()

Some issues with flake andblack have been introduced in the last PRs.

Build the CICD pipeline for Odoen based on the python ml skeleton project: https://github.com/samysung/python_ml_project_skeleton

Merge it directly on the main branch.

Feature 1A: Requirement for a modular installation, capable of adapting to OS environment contexts and hardware (with or without GPU) for dependency installation. This involves firstly a complete installation via pip install, then doing the same with conda (offering different configuration files). Hence, it will be necessary to manage these cases: Linux or Windows with an Nvidia GPU on one side (appropriate version of PyTorch), CPU (all macOS + Linux or Windows without GPU), and HPC (consider an environment variable, which, if present, switches a CPU environment to GPU even if no GPU is present).

Feature 1B: Initial version of GitHub Action workflow. Automate the triggering of pre-commits on each push, run tests during a pull request on the protected branches main or dev, and when integrating a version tag on the main branch. Generate documentation upon adding a version tag and/or merging into main.

Pass Odeon to 0.4.0