Registry - ModelVersion

The ModelVersion object is one of the most important objects you will manipulate on Picsellia.

It has a complete structure that aims to allow users to use them for many different purposes:

• Store model files and bring structure to your Computer Vision environment
• Use it as a Base architecture for a future Experiment (in this case the ModelVersion is marked as Trainable)
• Deploy it and make it ready to perform inferences (in this case the ModelVersion is marked as Deployable)

Depending on the usage, some items need to be related to this ModelVersion. The purpose of this page is to review all the items that compose a ModelVersion on Picsellia and detail their necessity depending on the usage.

1. ModelVersion overview

When opening a Model, all of its associated ModelVersion are displayed.

For each ModelVersion related to the current Model, the following details are displayed on the ModelVersion card:

• Name
• Description
• Number of Label in the LabelMap
• Label Names of the LabelMap
• Framework
• Detection Type
• Last update date
• The picture of the ModelVersion creator

Then, by clicking on a ModelVersion card, the ModelVersion overview opens.

This overview aims to give a complete and comprehensive idea of the ModelVersion to ensure traceability and reproducibility.

For the rest of this page, we will deep dive into each item displayed in the ModelVersion overview.

📘

ModelVersion & Experiment have a strong relationship

Across the different items available in the ModelVersion overview, you will easily understand that ModelVersion & Experiment have a strong relationship in Picsellia.

Indeed, many attributes of a ModelVersion are actually inherited from its source Experiment, similar to how Experiment attributes are inherited from the selected Base architecture, which is often a ModelVersion.

There exists a cyclical mechanism between ModelVersion and Experiment. This mechanism facilitates the frequent retraining of the ModelVersion while preserving traceability and structure in your project.

2. The About section

Each ModelVersion has an About section. These pieces of information are mainly contextual to the ModelVersion and also ensure its traceability:

• Name: The ModelVersion Name is mandatory. It is required when creating a new ModelVersion either by exporting an Experiment or by creating it from scratch under a Model in the Model Registry
• Description: The ModelVersion Description is optional. It can be filled when creating a new ModelVersion either by exporting an Experiment or by creating it from scratch under a Model in the Model Registry
• Version: This field is an integer automatically generated by Picsellia and used to uniquely identify the ModelVersion under a given Model
• Framework: The ML Framework used by the ModelVersion. This field is optional. However, if the ModelVersion is created by exporting an Experiment, the Framework value will be inherited from the Base architecture used in the Experiment. In case the ModelVersion is manually created from the Model Registry, the Framework can be selected among Tensorflow, Pytorch, and ONNX
• Type: The Detection Type related to the current ModelVersion. This field is mandatory. However, if the ModelVersion is created by exporting an Experiment, the Detection Type value will be inherited from the Experiment. In case the ModelVersion is manually created from the Model Registry, the Detection Type can be selected among Classification, Object Detection, Segmentation, Point, Line.
• Updated at: This field displays the date of the last modification done on the current ModelVersion. This date is automatically generated and cannot be modified by a user.
• Created at: This field displays the creation date of the current ModelVersion. It is automatically generated and cannot be modified by a user.
• Created by: This field displays the user who created the current ModelVersion. It is automatically generated and cannot be modified by a user.

📘

How to update the Name and Description?

From the UI authorized users can modify the Name and Description of a ModelVersion. It can be done in the Settings page of the ModelVersion in the General tab, as show below:

3. Labels

The Labels table represents the LabelMap of the ModelVersion.

Having a LabelMap attached to a ModelVersion is optional.

In case the ModelVersion is generated through the export of a Experiment, the LabelMap will be inherited from the LabelMap of the source Experiment if it exists.

In case the ModelVersion is manually created from scratch, the user can initialize the LabelMap by prompting the different Label (and associated indexes) in the ModelVersion creation form. More details are available in this section.

The LabelMap of a ModelVersion can be updated manually at any moment by clicking on the pen icon if the user has the permission to do so:

A. Add a new Label

A new Label can be added to the LabelMap by filling the Index & Name fields and cliking on +, where Index is a unique integer and Value is the name of the Label. In case you are adding a new Label with an Index that is already used by another, the existing one will be overwritten with the new Name.

B. Modify a Label

You can also modify an existing Label by clicking on the pen icon next to the to-be-updated Label. The Index and Name of the to-be-updated Label will then be displayed in the free-text field letting you update them. The existing Label that is being updated is highlighted in blue. To finish the modification of the Label, you just need to click on the blue pen icon as shown below:

Once the modifications on Labels are over, you need to click on Update to save them.

C. Delete a Label

A Label can be deleted from the LabelMap by clicking on the Trash icon next to it.

🚧

Watch out! Updating theLabelMap can severely impact your project

In cases where your ModelVersion is exported from an Experiment, the LabelMap is automatically generated through inheritance from the Experiment. This ensures consistency in the LabelMap from the DatasetVersion attached to the Experiment. Modifying the LabelMap of a ModelVersion can jeopardize this consistency between the ModelVersion and the DatasetVersion used for its training. Additionally, it can lead to inconsistencies when deploying the ModelVersion, particularly in setting up the Pipeline for Continuous Learning. More details available here.

As a general rule of thumb, you need to be very careful when modifying a LabelMap as it can endanger your projects' consistency.

4. Parameters

The Parameters table basically represents the training parameters related to the current ModelVersion.

These Parameters are the ones that will be available for the user when using the current ModelVersion as a Base architecture in an Experiment. The values associated with each parameter are the values assigned by default when using the current ModelVersion as Base architecture, but as explained here, those values can be manually modified in the Experiment creation form. As a reminder, those parameters and their associated values will be pulled by the training script when launching the training.

So it is crucial to ensure that the Parameters defined are the ones required by the associated training script.

In case the ModelVersion is generated through the export of a Experiment, the parameters will be inherited from the ones of the source Experiment if existing.

In cases where the ModelVersion is manually created from scratch, the user can initialize the Parameters table by entering them along with their associated default values in the ModelVersion creation form. More details can be found in this section.

The Parameters of a ModelVersion can be updated manually at any moment if the user has permission to do so, by clicking on the pen icon as shown below:

The Update Parameters modal will open.

A. Add a new Parameter

A new Parameter can be added by filling the Name & Value fields and clicking on +.

In case you are adding a new Parameter with a Name that is already used by another, the existing one will be overwritten with the new Value.

B. Modify a Parameter

You can also modify an existing parameter by clicking on the pen icon next to the Parameter you want to update. The Name and Value of the selected parameter will then be displayed in a free-text field, allowing you to make updates. The Parameter being edited is highlighted in blue. To finalize the modification of the Parameter, simply click on the blue pen icon, as shown below:

Once the modifications on Parameters are over, you need to click on Update to save them.

C. Delete a Parameter

A Parameter can be deleted from the LabelMap by clicking on the Trash icon next to it.

🚧

But, the Parameters table is different from the Parameters list in the Source Experiment section!

The Parameters table, located adjacent to the Labels table, displays the Parameters (and their associated values) that will be available if the current ModelVersion is used as a Base architecture.

Conversely, the Parameters list in the source Experiment section shows the parameters and their associated values that were used to train the current ModelVersion (in cases where it has been created through the export of a Picsellia Experiment). Unlike the Parameters table, this Parameters list cannot be edited.

5. Docker Image

As already detailed here, Picsellia enables users to directly trigger the execution of a training script from an Experiment.

From the Picsellia platform, the training script can be executed on the Picsellia Training Engine (hosted by OVH) or directly on the user's computing resources. In both cases, this remote execution is possible only if the training script has been dockerized and the related Docker Image attached to the Experiment.

The Docker Image used for the Experiment is pulled from the attached Base architecture.

As a consequence, each ModelVersion includes an optional Docker Image.

This item aims to ensure that you can retrieve easily the training script used for the current ModelVersion but also to provide a Docker Image for further Experiment that will use the current ModelVersion as Base architecture.

📘

Ensure the Docker Image is accessible

It is crucial to ensure that the Docker Image is accessible for pulling from the computing resource used.

To achieve this, the Docker Image must be available either on a Public Docker Hub or on the Private Container Hub provided by the Picsellia team.

In case the ModelVersion is generated through the export of a Experiment, the Docker Image will be inherited from the Docker Image of the Base architecture of the Experiment, if existing.

In case the ModelVersion is manually created from scratch, the user can initialize the Docker Image by prompting it in the ModelVersion creation form. More details are available in this section.

The Docker Image of a ModelVersion can be updated manually at any moment if the user has permission to do so, by clicking on the pen icon as shown below:

A modal will open displaying all the required fields to properly the Docker Image:

Once, the modification on the Image, Tag, Flags, or Environment variables are filled, you just need to click on Update to save them.

6. Files

All of the ModelVersion artifacts are displayed under the Files section.

Please note that the files are physically stored through the default Storage Connector of the current Organization. More details are available here.

Each Model file is displayed as a card, the following details are available:

• Name
• filename
• Creation date
• Size category (large or small)
• Author picture

Having a clear view of the Model files of a ModelVersion allows a better understanding of its structure (i.e. for instance weights, checkpoint, config file...).

Model files are also inherited as Artifacts when the current ModelVersion is selected as a Base architecture of a further Experiment. These inherited Artifacts are intended to be updated according to the outcome of the training script that will be executed in the frame of the Experiment.

Furthermore, if the ModelVersion is generated through the export of an Experiment, the Model files will be inherited from the Artifacts of the Experiment, if they exist.

When the ModelVersion is manually created from scratch, once initialized, users can add Model files by clicking on the + button. A modal will then appear, allowing for the upload of the file and specifying its Name. The Model file is created after clicking on the Create button.

More globally, a Model file can be attached to a ModelVersion at any time, regardless of the method of its creation, whether exported from an Experiment or created manually.

At any moment, any Model file can be downloaded or deleted using the respective buttons, as illustrated below:

7. Source Experiment

The Source Experiment section is read-only and displays information about the Experiment from which the current ModelVersion is exported.

If the current ModelVersion is manually created in the Model Registry, this section will be empty.

In this section, you will find key details about the Experiment used to create the current ModelVersion, including:

• A link to access the Source Experiment directly in Picsellia.
• The list of training parameters and their values from the Source Experiment used to train the current ModelVersion.
• The list of DatasetVersion and their aliases linked to the Source Experiment. Each DatasetVersion is a clickable link, directing you to that specific DatasetVersion.

8. Settings

From the ModelVersion overview, you can access the Settings tab from which you can edit the ModelVersion Name and Description.

From this view, you can also Delete the current ModelVersion, and Transfer it under another Model.