ModelVersion

The ModelVersion object is one of the most important objects you will manipulate on Picsellia. Its structure lets you use it for many different purposes:

• Store model files and bring structure to your Computer Vision environment.
• Use it as Base architecture for a future Experiment.
• Deploy it and make it ready to perform inferences either though the Picsellia serving engine or on your own device/cloud.

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, its Versions tab lists all of its ModelVersion in a table, with their Name, Description, Framework, Label, and creation date. A search bar lets you find a ModelVersion by name, and two sets of filters let you narrow the list down by type (Classification, Object Detection, Segmentation, Mask, Point, Keypoint, or Line) and by Framework (PyTorch, TensorFlow, ONNX, or Not Configured).

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

From the header of this page, you can also launch a processing on the ModelVersion with the Process button, detailed here, or deploy it with the Deploy button, detailed here.

The rest of this page details each item displayed in the ModelVersion overview.

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.
• 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.
• Version: 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. If the ModelVersion is created by exporting an Experiment, the Framework value is inherited from the Base architecture used in the Experiment. If the ModelVersion is manually created, the Framework can be selected among PyTorch, TensorFlow, and ONNX.
• Type: the type of the ModelVersion. This field is mandatory. If the ModelVersion is created by exporting an Experiment, the Type value is inherited from the Experiment. If the ModelVersion is manually created, the Type can be selected among Classification, Object Detection, Segmentation, Mask, Point, Keypoint, and Line.
• Updated at: the date of the last modification done on the ModelVersion. This date is automatically generated and cannot be modified.
• Created at: the creation date of the ModelVersion. It is automatically generated and cannot be modified.
• Created by: the user who created the ModelVersion. It is automatically generated and cannot be modified.

3. Labels

The Labels table represents the LabelMap of the ModelVersion.

Having a LabelMap attached to a ModelVersion is optional.

If the ModelVersion is generated through the export of an Experiment, the LabelMap is inherited from the LabelMap of the source Experiment, if it exists.

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

If you have the permission to do so, you can update the LabelMap of a ModelVersion at any moment: click on the pen icon next to Labels to open the Labels page of the ModelVersion Settings (Configuration > Labels).

This page lists every Label of the LabelMap with its index and its name. From there, you can:

• Find a Label with the search bar.

• Add a new Label with the Add Label button.

• Modify the name of an existing Label.

• Delete a Label from its "..." menu, or select several Label with their checkboxes and delete them at once with the trash icon.

  

4. Parameters

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

These Parameters are the ones available when using the current ModelVersion as Base architecture in an Experiment. The value associated with each parameter is the value assigned by default in that case, but as explained here, those values can be modified in the Experiment creation form. As a reminder, those parameters and their associated values are 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.

If the ModelVersion is generated through the export of an Experiment, the parameters are inherited from the ones of the source Experiment, if they exist.

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

If you have the permission to do so, you can update the Parameters of a ModelVersion at any moment by clicking on the pen icon next to Parameters. An Update parameters modal then opens, listing each Parameter with its value and type. In this modal, you can add a Parameter by filling its Name and Value, and modify or remove an existing one. Click on Update to save your changes.

5. Docker image

As already detailed here, Picsellia lets you trigger the execution of a training script directly from an Experiment: on the Picsellia training engine, on your own infrastructure through a Compute Connector, or directly on your own training resources. This remote execution is possible only if the training script has been dockerized and the related Docker image is 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 lets you retrieve the training script used for the current ModelVersion, and provides a Docker image for further Experiment that use the current ModelVersion as Base architecture.

The Docker section displays the Image, its Tag, the Flags used to run it, and the Environment variables passed to it, if any.

If the ModelVersion is generated through the export of an Experiment, the Docker image is inherited from the Docker image of the Base architecture of the Experiment, if it exists.

If the ModelVersion is manually created from scratch, you can initialize the Docker image in the ModelVersion creation form. More details are available in this section.

If you have the permission to do so, you can update the Docker image of a ModelVersion at any moment by clicking on the pen icon next to Docker. An Update Docker modal then opens with the Image, Tag, Flags, and Environment variables fields. Click on Update to save your changes.

6. Files

All 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 with the following details:

• Its Name and filename.
• A size category (Large or Small).
• Its last modification date and the picture of the user who modified it.
• A download button and a delete button.

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

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

If the ModelVersion is generated through the export of an Experiment, the Model files are inherited from the Artifacts of the Experiment, if they exist.

A Model file can be attached to a ModelVersion at any time, whether it was exported from an Experiment or created manually: click on the pen icon next to Files to open the Upload a file modal, give your Model file a Name, select the file to upload, and click on Create.

At any moment, any Model file can be downloaded or deleted using the buttons of its card.

7. Source Experiment

The Source Experiment section is read-only and displays information about the Experiment from which the current ModelVersion was exported. If the current ModelVersion is manually created, this section is empty.

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

• The source Experiment itself, shown as a card in the Overview column.
• The list of training parameters and their values used to train the current ModelVersion.
• The DatasetVersion attached to the source Experiment, shown as cards with their number of Asset.

8. Settings

From the ModelVersion overview, you can access the Settings tab, which has three entries.

A. General

The General tab lets you edit the ModelVersion Name, Description, and picture.

Its Danger zone lets you Transfer the ModelVersion to another Model under which you have the right to create versions, or delete it.

B. Constraints

The Constraints tab lets you define and modify the Dataset Constraints of the ModelVersion: sets of aliases that automatically assign a DatasetVersion to your training script when the ModelVersion is used as Base architecture of an Experiment. Each constraint defines a number of DatasetVersion and the alias of each one (for instance, 3 DatasetVersion with the aliases train, test, and eval).

The Required toggle sets whether these constraints must be fulfilled, and can be changed whenever you want. More details about Dataset Constraints and how they are applied during Experiment creation are available here.

C. Labels

The Labels tab, under Configuration, is where you manage the LabelMap of the ModelVersion, as detailed in section 3.