WO2022090883A1 - Procede d'annotation de donnees d'entrainement - Google Patents

Procede d'annotation de donnees d'entrainement Download PDF

Info

Publication number
WO2022090883A1
WO2022090883A1 PCT/IB2021/059800 IB2021059800W WO2022090883A1 WO 2022090883 A1 WO2022090883 A1 WO 2022090883A1 IB 2021059800 W IB2021059800 W IB 2021059800W WO 2022090883 A1 WO2022090883 A1 WO 2022090883A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
annotation
facet
view
region
Prior art date
Application number
PCT/IB2021/059800
Other languages
English (en)
Inventor
Vincent DELAITRE
Alois BRUNEL
Original Assignee
Deepomatic
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deepomatic filed Critical Deepomatic
Priority to US18/033,619 priority Critical patent/US20230394803A1/en
Priority to EP21795015.3A priority patent/EP4232970A1/fr
Publication of WO2022090883A1 publication Critical patent/WO2022090883A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00—Arrangements for image or video recognition or understanding
    • G06V10/70—Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/77—Processing image or video features in feature spaces; using data integration or data reduction, e.g. principal component analysis [PCA] or independent component analysis [ICA] or self-organising maps [SOM]; Blind source separation
    • G06V10/774—Generating sets of training patterns; Bootstrap methods, e.g. bagging or boosting
    • G06V10/7753—Incorporation of unlabelled data, e.g. multiple instance learning [MIL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/10—Terrestrial scenes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/50—Information retrieval; Database structures therefor; File system structures therefor of still image data
    • G06F16/55—Clustering; Classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/906—Clustering; Classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/21—Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
    • G06F18/214—Generating training patterns; Bootstrap methods, e.g. bagging or boosting
    • G06F18/2155—Generating training patterns; Bootstrap methods, e.g. bagging or boosting characterised by the incorporation of unlabelled data, e.g. multiple instance learning [MIL], semi-supervised techniques using expectation-maximisation [EM] or naïve labelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V2201/00—Indexing scheme relating to image or video recognition or understanding
    • G06V2201/02—Recognising information on displays, dials, clocks

Definitions

  • the present invention relates to the field of machine learning (or "machine learning” in English). More particularly, the present invention relates to the annotation of data used for machine learning or performance evaluation.
  • dataset sets of annotated data (called “dataset”). These are, for example, images, videos or the like. These datasets can also be used to evaluate the performance of machines by comparing their predictions on raw data to annotations.
  • the data is annotated by concepts that we seek to "teach” to machines so that they are able to predict them automatically on data (images, videos, etc.) which are subsequently given to them in entrance.
  • an image of a “dataset” containing a chat can be annotated with a label “chat”.
  • a label is thus metadata associated with the initial data which will inform the machine, during the training phase, about the concept that it must recognize there.
  • AI artificial intelligence
  • One of these steps may, for example, involve measuring the quality of the signal leaving the fiber with an optical power meter or “wattmeter”. The technician must then take a photograph of the power meter indicating on the screen a figure representing the quality of the signal. From the point of view of the AI application, it is natural to annotate the images in three hierarchical levels.
  • the first level of annotation could be the context in which the photo is taken. For example, it is a question of determining if the photograph represents the connection box in the cellar, the fiber outlet box in the place of life or the wattmeter. This is therefore a classification problem. Determine what is in the images.
  • the second level of annotation could be for each context, to annotate the information to be recognized.
  • the third level of annotation could be, in the case of the power meter screen, the annotation of the value indicated on the screen. This is an automatic character recognition (or "OCR") problem. We determine a text on the images.
  • OCR automatic character recognition
  • the different annotation levels can be as follows.
  • the first level of annotation can for example be the annotation of bounding boxes around the different dishes and a label according to the type of dish. This is a detection problem followed by a classification problem. We determine where an object is then we determine the type of this object (for example a starter, a main course, a dessert etc.).
  • the second level of annotation can for example be, for each type of dish, the fine annotation of the nature of the dish (for example for the "starter” type, it can be carrot salad, terrine , etc.).
  • the annotation of the data is conventionally done in a hierarchical manner and defines a tree (technically, the underlying structure is a forest because there can be multiple roots that give rise to multiple annotation trees).
  • the tree is not necessarily regular. There may be little depth level on one side and a lot on the other.
  • the standard practice of the state of the art is to constitute as many data sets as there are nodes in the tree.
  • the images are cropped around the objects of interest to normalize the data and facilitate the learning process of the AIs.
  • the images of the third level dataset in the fiber connection example would all be cropped so that the power meter screen covers almost all of the 'picture.
  • the image would typically be cropped using the bounding box of the second annotation level (to detect the presence of the screen).
  • each box on an image at a given level produces several images in the lower levels.
  • this solution does not make it possible to easily propagate the annotation changes, in particular in the case of the correction of initial annotation errors.
  • a plate was initially classified as being a main course, it will have been injected into the level 2 dataset corresponding to “Main courses” .
  • the state-of-the-art method which Breaking the problem down into different separate datasets is not going to reflect those changes. It will therefore be necessary to think of manually deleting the image from the level 2 data set “Main Courses” to put it in “Starters”.
  • a first aspect of the invention relates to a learning data annotation method for an artificial intelligence comprising the following steps: storing, in a database, a set of data to be annotated, storing, in said base of data, at least a first description of a first data selection facet in said data set, said first description being associated with a first task to be executed by said artificial intelligence, selecting said first facet in said database data, applying said first facet to data of said data set to obtain first filtered data, receiving at least a first annotation of said first filtered data, and storing said first annotation in the database in association with said first facet.
  • said database includes a plurality of descriptions of a plurality of data selection facets in said data set and said first description includes a hierarchical link to a second des- writing a second facet of data in the database, said first facet is applied to second filtered data obtained by applying said second facet to data of said set of data.
  • said second facet relates to a plurality of sub-regions in said set of data, and the first facet is applied to each region to which the second facet relates.
  • annotations are associated with some of said regions to which said second facet relates as well as with said second facet, and the first facet is applied to each region bearing an annotation associated with the second facet.
  • the description of the first facet comprises a filtering condition applied to the annotations associated with said regions as well as with said second facet and in which the first facet is only applied for the regions for which said filtering condition is verified.
  • said filtering condition is associated with the regions annotated by said second facet and in which the first facet is only applied to the data resulting from a cropping by these regions and for which the condition is verified.
  • said annotation generates the definition of a region in said set of data
  • said region is stored in the database in relation to the region having been used to crop the annotated data
  • said annotation is stored in said database in relation to said first facet and said region.
  • said annotation does not create a new region and in which said annotation is stored in said database in relation to said first facet as well as the region having been used to crop the annotated data.
  • the method may further comprise a step of displaying said first filtered data for a user, said annotation being received from said user.
  • said first filtered data is supplied as input to an artificial intelligence module implementing said task, said annotation being received from said module.
  • a second aspect of the invention relates to a machine learning method, for the execution of a task by an artificial intelligence, comprising the following steps: accessing a database comprising a set of data and at least one definition of at least one data selection facet in said set of data, said one definition further comprising at least one annotation associated with said facet, applying said data selection facet to said data set to obtain first filtered data, storing said first filtered data in an annotated training data memory, associating said first data filtered to annotations performing said task by said artificial intelligence.
  • said annotation is generated according to a method according to the first aspect of the invention.
  • a third aspect of the invention relates to a device comprising a processing unit configured for the implementation of steps according to a method according to the first and/or the second aspect(s).
  • fig-1 [fig.1] illustrates data annotation for a root view according to embodiments.
  • fig.2 illustrates data annotation for a region-creating child view according to embodiments.
  • fig.3 illustrates a context for using data annotation for a non-region-creating child view according to embodiments.
  • fig.4 illustrates the fact that a datum is not annotated by a child view when the condition thereof is not satisfied according to embodiments.
  • FIG.5 [fig.5] schematically illustrates an annotation interface according to embodiments.
  • FIG.6 [fig.6] schematically illustrates an annotation statistics interface according to embodiments.
  • FIG.7 [fig.7] schematically illustrates an interface for accessing non-annotated images according to embodiments.
  • fig.9 schematically illustrates the structure of a database according to embodiments.
  • fig.10 schematically illustrates an example of image annotation from a helpdesk application to a fiber patch according to embodiments.
  • FIG.11 [fig.11] schematically illustrates an annotation method according to embodiments.
  • FIG.12 [fig.12] schematically illustrates an annotation method according to embodiments.
  • fig.14 [fig.14] schematically illustrates a use of annotations produced according to embodiments.
  • fig.15 schematically illustrates a device according to embodiments.
  • the embodiments of the invention make it possible to manipulate and store the hierarchical character of the annotated concepts, to annotate more efficiently and to decouple the notion of machine learning model from the notion of data set (or " dataset” in English).
  • the embodiments take advantage of the hierarchical structure of the data to be annotated to facilitate the annotation even though this hierarchical structure is a source of problem in the prior art.
  • the embodiments make it possible to respond to the problem of error propagation in the models of the prior art. For example, they make it possible to automatically take class changes into account in order to pass them on automatically.
  • the embodiments also make it possible to annotate data without causing inflation thereof as the annotation progresses.
  • the generation phase of the actually annotated data can be postponed to an effective training phase.
  • the annotation according to the embodiments takes into account the hierarchical structure of the annotations to be performed.
  • a Automatic cropping of data around relevant regions to be annotated can be performed for annotation without generating new data subsets. It is also possible to filter the images to be annotated to display only the relevant data regions.
  • the embodiments of the invention will not attempt to create “sub-datasets” as annotations are made on the data from the datasets.
  • the inflation of the dataset by the annotation process which is the source of the propagation of errors in the prior art is not repeated.
  • the initial dataset will be kept and a dynamic dataset construction system (the “facets” or “views”) will be created with which the annotations will be associated.
  • facets or “views”
  • views the “facets” or “views”
  • the "sub-datasets” will be generated on demand, according to the desired use (for example the training of an AI) once the construction system has been validated.
  • a set of unstructured data to be annotated to allow the training of an artificial intelligence on a certain number of tasks is considered.
  • Data refers to any type of data that can typically be produced by a sensor, a capture device or a manual input device. It can be an image, a video stream, a point cloud, a 3D image made of voxels, a sound stream, a text, a time series, etc. .
  • Annotations are the additional information linked to a datum and relating to its content. For example the position of an object in an image and/or its "class” (or "type”).
  • a “task” designates any action of a machine allowing it to automatically predict the annotations of a datum, or a subset of the annotations.
  • a large number of tasks can be mentioned. A few examples are cited below.
  • the annotation to be predicted is an object category, otherwise called a “class”, from a predetermined list of possible classes. For example, given a photo of an animal, we try to find out which animal it is.
  • the annotation to be predicted is a list of objects present in the image from a list of classes of interest.
  • Each predicted object must indicate a simple delimitation of the object, typically in the form of a bounding box as well than his class. For example, given a video captured by an autonomous car, we want to know where all the vehicles, pedestrians, cyclists, etc. are.
  • the annotation to be predicted is the same as for a detection task, but the objects must be delimited to the nearest pixel.
  • the aim is to predict the text present in an image. For example, reading a license plate number from a plate photo.
  • a pose estimation task it is a question of predicting the “pose” of a deformable object. Typically, key parts of the object are identified beforehand and linked by a tree. It is then a question of predicting the position of the various nodes of the tree if they are visible or of indicating that they are invisible. For example, in the case of estimating the pose of a person, one typically seeks to locate the head, hands, feet, etc. of each person in the image.
  • a regression task For a regression task, it involves predicting a number or a vector (i.e. a list of N numbers, N being known beforehand). For example, it involves predicting a person's age given a photo of a face.
  • the hierarchical relationship between a task A and a task B can for example appear when the need to annotate data for task B depends on the annotation of these data for task A. This is for example the case where the need to annotate for task B depends on the class of object indicated in A.
  • it is for example the annotation of the power meter screen which is only relevant in the context where the image actually shows a power meter and has been annotated as such in the first level of annotation. It is therefore a question of being able to “filter” the regions to be annotated for task B according to a certain condition on the annotation of task A.
  • the hierarchy relationship can also appear when task B consists of annotating the same data regions as those defined by task A.
  • task B consists of annotating the same data regions as those defined by task A.
  • it is for example annotate the nature of the dish on the image resulting from the cropping of the original image by the region defined in task A.
  • Hierarchy relationships can appear for any other reason that leads to the fact that the annotation for task A can be directly reused to define the need annotation or simplify the annotation process for task B.
  • a region is called a sub-part of a datum defined by its extremal values on the different axes of the datum (x, y, z for spatial data and/or t for video).
  • the spatial position i.e. in x, y, z
  • the interest of a region is to be able to reframe a datum to produce a new (sub-)datum to annotate.
  • each annotation task is assigned a unique facet of its own (i.e. a task is linked to a unique facet and vice versa).
  • a facet is understood by analogy with the term facet in the field of information retrieval based on a facet classification, which gives users the ability to filter the data according to the selected facet. In what follows, and without losing generality, the term "view" is used.
  • a view can be hierarchically attached to another view, called “parent view” or “parent” (or conversely a “child view” or “child view”).
  • a view that does not have a parent view is called a “root view”.
  • a view When a view is a child view, it defines a “filtering condition” on the annotation of the parent view, or “condition”. The data from the parent view satisfying the condition defines the child view. This allows to create sub datasets.
  • An annotation process can have several root views. Formally, the relationship between the views induces a forest structure in the sense of a set of disjoint trees as defined in graph theory.
  • the views as defined above make it possible, in the embodiments of the invention, to filter and crop the regions produced by the parent view in order to present to the user who performs annotation, valid data and centered on regions of interest. As explained in the following, this allows for more efficient annotation. This also makes it possible to manipulate data on the fly in the annotation phase and to reserve the generation phase of annotated datasets for the AI training phase.
  • each data has at least one root view.
  • DXR ⁇ D which takes as input a datum d and a region f and returns the sub-data resulting from the reframing of d by r . Cropping by a root region does not modify the data:
  • regions(j, r) The set of regions covered by the annotations of a region r by the view v j is denoted regions(j, r).
  • R i, j the set of regions to be annotated for the view v j on the data.
  • R i, 0 ⁇ r i, o ⁇ , such that a .
  • the data presented to the annotation for the view v j are all the data reframed by the regions to be annotated, i.e.
  • D j ⁇ crop ( d i , r)
  • the creation of the notion of “view” allows dynamic annotation of the data, which has the consequence of not creating sub-datasets as the annotation progresses.
  • the case of a root view v j 101 is illustrated where the datum presented to the annotation is exactly the raw datum of the set of data to be annotated. Indeed, the region to be annotated is necessarily the root region 103 which includes all the data d i 102. This is found via the formalism above because and therefore the data presented to the annotation is The root view 101 therefore behaves like a task of “standard” annotation which would follow the practices of the state of the art according to which one adds the annotations 104 to the data set D for the task linked to v j. The difference is that the annotation is attached to the root region 103 and not directly to the data 102. In the case where there are several root views, all the annotations are attached to the same root region 103.
  • region 205 (solid line) verify a condition B while those of region 204 do not verify it (dotted line).
  • region A 205 verifying condition B will be presented for the annotation according to view B.
  • the datum resulting from a cropping by region 204 is not presented.
  • the data to be annotated for view B 202 are the initial data cropped by the regions annotated by view A 200 whose annotation verifies condition B.
  • the The annotation 209 is associated with the region 205 which was used to reframe the annotated data.
  • the dataset would include the datum 203 cropped by the region 208, annotated by two regions (for example bounding boxes and their classes) 204+206 and 205+207.
  • view B which could be a classification view, the dataset would include data 203 cropped by region 205 and annotated by 209.
  • the datum 203 is not modified and the annotations are not added directly to it. Instead, we create a representation of views A and B, as well as regions, and associate the annotations with these regions.
  • views A and B as well as regions, and associate the annotations with these regions.
  • the annotation process there is no creation of new data subsets. Only views are used to generate the data to be annotated and allow the user (or an automatic process) to annotate it. These same views can be used to effectively generate the annotated data to give them as input to an AI in the training phase.
  • the storage and processing of annotations is greatly facilitated because the hierarchy between the annotations is automatically preserved, which makes the process of updating (modifying or deleting) the annotations more reliable.
  • the parent view A does not create new regions (for example in the case of a classification task).
  • the annotation for view B covers the same regions as view A.
  • a parent view A 300 (parent of view B 301) to a datum 302 resulting from the set of data to be annotated. As indicated, this parent view A 300 does not create new regions as before. We therefore find after the application of the view A 300, the same region 303. This region is associated with the annotation 304. It is assumed that the view A applies to a root region 303 to simplify the figure (one could consider the case of a region that is not).
  • annotations 304 verify the condition of view B 301.
  • the datum to be annotated for view B 301 is then the initial datum 302 cropped by region 303. That is to say that already annotated by view A 300.
  • annotation 305 is associated with region 303.
  • the dataset would include data 302 cropped by region 303 and annotated by 304.
  • view B which could also be for example a classification view, the dataset would include data 302 cropped by region 303 and annotated by 305.
  • the data region will not be presented to the user for annotation and no annotation will be added (the annotation 305 is absent).
  • a user can for example access an interface 500 of an annotation system as illustrated by [fig.5]. This interface is used to display the views and to manipulate the hierarchies between them.
  • the interface 500 includes an action zone 501 including various buttons 502 (ACT1), 503 (ACT2), 504 (ACT3).
  • buttons 502 ACT1
  • ACT2 ACT2
  • ACT3 ACT2
  • 504 ACT3
  • these buttons allow the user to manage the dataset in general, such as adding data, viewing view mapping, deleting images, etc.
  • the interface 500 also includes a zone 505 for displaying the root views.
  • a root view 506 VI is shown.
  • Other root views may be present in this area.
  • a button 508 allows the user to add root views.
  • a view for example 506, and a zone 509 similar to 500 appears to display the child views of the selected view.
  • views 510 (V1.1), 511 (V1.2), 512 (V1.3) depend on view 506 (VI) which is therefore a parent view for them.
  • a button 513 allows the user to add views dependent on the view selected in the zone 500. For example, the user selects the view 506, then clicks on the button 513 to create a view dependent on view 506.
  • a zone 514 makes it possible to display views dependent on the view selected in the zone 509 and a button 515 makes it possible to add a dependent view to the selected view.
  • the view 511 is for example selected but does not contain a child view. The user then clicks on the button 516 to create a first view dependent on this selected view.
  • the [fig.6] illustrates an interface 600 comprising an action zone 601 with a set of buttons 602 (ACT4), 603 (ACT5), 604 (ACT6).
  • buttons 602 ACT4
  • ACT5 ACT5
  • 604 ACT6
  • these buttons allow the user to annotate images, correct annotations, add concepts to recognize, etc.
  • the interface 600 also comprises an area 605, with a certain number of windows allowing the user to manage the images of a view.
  • a window 606 (DISTRI IMG) gives access to a distribution of the images of the view between different uses (it is possible to find the number of training data, of non-annotated data, or other). This allows you to know what use the images in the view are intended for.
  • a window 607 (DISTR2 CNCPT) gives access to another distribution concerning the concepts that the machine will have to predict. For each concept, we can see the number of images associated with it.
  • a window 608 can give access to the number of images in the view.
  • a window 609 (CNCPT) gives access to the number of concepts associated with the view.
  • buttons in area 601 can give the user access to images not annotated in an interface 700 illustrated by [fig.7].
  • This interface 700 includes an action zone 701 with a certain number of buttons 702 (ACT7), 703 (ACT8), 704 (ACT9) allowing the user to perform a certain number of actions.
  • buttons 702 (ACT7), 703 (ACT8), 704 (ACT9) are for example the same as those of the 600 interface or can be supplemented by others.
  • it may comprise a button opening the possibility for the user to annotate an image not yet annotated, thanks to an annotation interface making it possible to carry out an annotation specific to the type of task linked to the view selected in the interface 600.
  • This interface complies with the practices of the state of the art and is not described here. That said, contrary to the state of the art, it does not apply directly to the annotated data but to the region of interest as described in [fig.8] below.
  • the interface 700 further comprises an area 705 with all the images 706 (IMG) not yet annotated. For example, the user selects an image in the area by clicking on it and is redirected to the image annotation interface for the selected task and view as before.
  • IMG images 706
  • the process is shown schematically in [fig.8].
  • the user typically annotates the data one after the other.
  • the stream of regions annotated 803 (REG) by the parent view of the view selected for the annotation, called the current view below. If the current view is a root view (ie it has no parent view), then this stream consists of all the root regions.
  • the regions are filtered by the condition to be applied for the annotation according to the current view.
  • the useful regions 804 (REG_CHLD) for the desired annotation.
  • step 801 CROP
  • the data to be annotated are presented, cropped by the useful regions 804.
  • the stream of data to be annotated 805 (DAT) is thus obtained which is then annotated during step 802
  • the annotations are attached to the useful region 804 and not to the data generated by the reframing 805, so that the latter can be deleted once annotated.
  • In Output of the process is the annotated region stream for the current view 806 (REG_ANNOT). It is this stream of annotated regions that will be used instead of stream 803 for all child views of the current view. Unlike the prior art, a stream of annotated data is not directly obtained, but a stream of annotated regions, themselves linked to the data which carries them and which is not duplicated.
  • Step 802 is then implemented by the annotation module. Cropping is still performed to present the data to the module but it is no longer useful in this case to display the result.
  • This embodiment can be useful in cases where an artificial intelligence is already sufficiently trained and gives sufficiently satisfactory results to be able to convert a prediction into an annotation when the confidence score is high enough. We then allow the artificial intelligence to enrich itself by giving it new annotated images.
  • the notions of data, views, regions, annotations are stored in a database.
  • a query to the database is performed to obtain (i) all the root regions if the current view is a root view and (ii ) all regions already annotated in the parent view and which otherwise satisfy the current view's condition.
  • the task linked to the view does not create a new region but merely enriches the region passed as input (as for example in the case of classification) then the newly created annotation is linked to this region and it is considered as annotated for the current view. The annotation then becomes available for annotation in child views.
  • one of the annotation difficulties consists in verifying whether the condition for filtering the child views is not violated, and if necessary in correctly deleting the annotations that have become invalid.
  • a region stores the view that created it so that all regions and annotations from a given view and its children can be efficiently deleted when that view is deleted.
  • the [fig.9] illustrates a database according to embodiments according to a UML-type schematization.
  • both the data 901 and the views (with their conditions) 902 are linked to the dataset 900 to which they belong.
  • the regions 903 are for their part linked to the data 901 and to the views (with their conditions) 902 which carry them.
  • the view table is linked to itself in [fig.9].
  • regions can store their parent region as explained above.
  • the annotations 904 inherit both the regions 903 and the views and conditions since the annotations are linked to one and the other.
  • FIG. 9 a diagram of the same type is also represented in FIG. 9 for an annotation database according to the prior art.
  • the structure is much simpler since the annotations 907 are linked to the data 906 which are themselves linked to the dataset 905.
  • the database according to the prior art does not have the notion of view which allows the creation at the fly of data to annotate according to the annotations of the previous step when the annotation task is hierarchical.
  • VI first root view v1 of classification 1000
  • Context two classes (or type): “Wattmeter” and “Cabinet”.
  • V2 1001 V2
  • Screen a detection view v2 1001
  • This view 1001 has a condition.
  • the region must be annotated “Wattmeter” in the parent view for an annotation to be associated with an image of this view.
  • This view has a condition. The region must be annotated “Cabinet” in the parent view for an annotation to be associated with an image of this view.
  • Each data item carries regions organized in the form of a tree from of a root region that encompasses all the data.
  • An annotation is attached to a region and a view.
  • the annotation can be a class, text, etc.
  • Each view has a type and possibly a condition.
  • Image 1007 represents a wattmeter.
  • a first region 1009 is then defined which is a root region.
  • a sub-region 1010 is also defined around the screen of the wattmeter.
  • the region 1009 is thus annotated 1011 according to the "Wattmeter” class.
  • the region 1010 for its part receives two annotations: one is the “Screen” class 1012 and the other is the text recognized by OCR on the screen 1013 for example “-4.6 dB”.
  • the annotations 1011, 1012, 1013 are thus respectively associated with the views 1000, 1001, 1002.
  • Image 1008 shows a connection cabinet.
  • a first region 1014 is then defined which is a root region.
  • a sub-region 1015 and a sub-region 1016 are also defined which correspond to two different areas of the cabinet.
  • the region 1014 is thus annotated 1017 according to the “Cabinet” class.
  • the region 1015 for its part receives an “OK” annotation 1018 because it comprises a compliant connection zone.
  • Region 1016 receives a "KO" annotation 1019 because it has a nonconforming splice area.
  • Annotation 1017 is associated with view v 1 1000 because the presence of the cabinet is an annotation of "Context”.
  • the annotations 1018 and 1019 are both associated with the v4 view 1003 because the good or bad connection is a “Connection” annotation.
  • the condition of a view v j can for example relate to the class annotated in the parent view (if this is unique, see paragraph below for the multi-class case) to restrict the annotation of v j to certain classes only. This makes it possible, for example, to specialize views to certain shooting or object contexts, typically in order to structure and simplify the annotation work in order to have fewer classes (or types) to annotate.
  • the class function can be represented by class ; ' classes acceptable as a logical formula boolean on the classes: -
  • This variant actually encompasses the previous case where there is only one annotated class at a time.
  • the annotation of the parent view does not include any notion of class, as for example in the case of the pose estimation or a textual annotation, it is possible to define “clusters” on which you can also apply conditions.
  • clustering is used when the annotation of a view v j does not directly provide a class (or type). This is for example the case for a pose estimation task where the annotation corresponds to placing the nodes of a tree on the data. It is then possible in this case to calculate beforehand a partition of the space of the annotations (clustering in English). This method divides the space A . into A r groups (or “clusters”) and any annotation can be associated. to the nearest cluster, i.e. we have a class function. : which allows to associate a class to a annotation.
  • each annotation can be associated with several clusters and the class function has the general form class ' A ⁇ 0,1 ⁇ /V - We then fall back exactly into the case of the previous paragraph for the case of the multi-class annotation.
  • a task can be divided over several views in order in particular to reduce the number of classes to be annotated in each view. That allows a person (or an annotation module) annotating to focus on fewer classes, thus being more efficient and making fewer errors.
  • the view system makes it possible to automate the handling of data and annotations, so that the data flow annotated by the different views corresponds to a set of datasets which would share a structure hierarchical.
  • this scheme once data has been annotated for a given view, one can then train a machine learning model on the dataset that corresponds to the annotated data for that view.
  • This method can be implemented in the case of an annotation application implemented by computer, with for example an interface as described above. It is thus a user who interacts with the application, via the interface to annotate the data. Variants of the method can also be implemented in the context of automatic annotation, by an AI for example.
  • the user can for example create an annotation project in which data to be annotated and annotations will be stored according to the invention.
  • This is, for example, a “Meal trays” or “Fibre Paccordment” project.
  • step 1101 the description of a view, corresponding to a project task, is created. It is then determined (step 1102) whether this view is a root view. If this is not the case (N), the process continues with the selection of the parent view during step 1103.
  • the interface of [fig.5] can for example be used, for example it is determined whether it is the button 513 or 515 which has been activated. In this case the determination of the parent view is done by determining the view previously selected by the user before clicking on one of these buttons. If button 508 has been activated, then it is determined (Y) that the view created is a root view.
  • a condition on this parent view is defined (step 1104) to make it possible to filter the data to be proposed for annotation for the view created at step 1101.
  • the exact form of this condition depends on the task type of the parent view. For example, if the parent view is a classification or detection view where only one class can be annotated, the condition can take the form of a drop-down list in which the user selects the different parent classes of interest, which allows to define the set C . acceptable classes defined above. If the type of parent task is multi-class and allows several classes to be annotated on the same region, the condition may be defined by a Boolean formula whose clauses relate to the presence of certain parent classes.
  • the type of annotations for this view is created (step 1105), that is to say the type of associated task (classification, OCR, pose, detection or other).
  • the configuration of the annotation is then defined (step 1106). For example for annotations based on classes, we define the classes of interest: "Screen" or
  • step 1102 (Y) If the view created is a root view, the process goes from step 1102 (Y) to step 1105 directly.
  • step 1201 the annotation process is described. It begins with the selection of a view v j during step 1201. It is then determined during step 1202 whether the selected view is a root view or not.
  • a loop is initialized (step 1203) during which all the regions not yet annotated according to the current view are determined (step 1204). We therefore iterate over the root regions of the data in memory: if the region is not annotated by the view v j, the latter is selected (step 1205). Otherwise (N) the region is ignored. The iteration is typically done via a query to a database but can be implemented by a counter i which traverses all the root regions. In step 1206, if i has not yet finished iterating over the root regions (N), the loop is incremented (step 1207) or else (Y), if all the regions have been tested, one goes to a step 1208 for storing all the regions filtered in step 1205. This is not not a storage of a new dataset or the creation of a sub-dataset but the memorization of all the regions to be annotated according to the current view, typically according to a cursor returned in response to the request to the database data.
  • This step is a prerequisite for displaying the data for the user, for example to prepare the display of the data to be annotated in the area 705 of the interface 700 of [fig.7],
  • step 1202 if the view selected is not a root view (N), then a loop is initialized (step 1209), during which, one determines (step 1210) all the regions of the data annotated by the parent view.
  • step 1211 For each region annotated by the parent view (Y), it is determined whether it is annotated by the current view during step 1211. If the region is not annotated by the current view (Y), then determines (step 1212) if the parent view's filter condition is met for the current region. If the condition is respected (Y), then the region is selected (step 1215) to present it for annotation.
  • step 1216 If there are still regions to consider (N), the loop is incremented in step 1217 and resumed in step 1210. Otherwise (Y), the process ends with step 1208 already described by storing the regions filtered during step 1215.
  • step 1216 As illustrated by [fig.12].
  • the data corresponding to the regions to be annotated stored in step 1208 are either displayed for annotation by a user, for example via the interface 705, or supplied to an automatic annotation module.
  • step 1208 For each region r stored in step 1208, the user (human or algorithm) is presented with the datum d to which r is attached, cropped by 1 .
  • the datum crop d, r is presented to the user for annotation according to the view v j selected at 1201.
  • step 1301 an annotation is received for this datum. It is then determined in step 1302 whether the type of task type linked to v j is region-creating. If this is not the case (Y), then we pass to step 1303 of memorizing the annotation. As already indicated, this storage is done in connection, not with the data but with the current view and the region to which the data belongs.
  • the annotation creates one or more regions (N), denoted for example if it this is a view linked to a detection task, we pass to a step 1304 of storing a relationship between the created regions and the regions from which they come. We then proceed to a step 1305 of storing the annotation in connection with the region created and the current view and this, for each of the regions created. For example, in the context of detection, a class annotated on a bounding box is associated with the corresponding region.
  • Only visualization can be performed temporarily to allow the user to visualize the data of the sub-datasets and annotate them or to allow an automatic process to take them as inputs and annotate them. This process being carried out data by data, it remains light and does not present any complexity of execution.
  • the generation of the datasets is then done when training the AI. Either it is done all at once, or on the fly as the training progresses.
  • the [fig.14] illustrates a use of annotations produced according to embodiments.
  • step 1401 The process is initialized by step 1401 during which the annotations are accessed, for example a database according to FIG. 9.
  • a loop is then initialized (step 1402) during which the different views v j (step 1403) and they are applied to the initial data during step 1404.
  • the result of the filtering is stored in memory during step 1405, with the annotations associated with the view v j.
  • the annotations associated with the view v j are stored in memory during step 1405, with the annotations associated with the view v j.
  • step 1406 It is then checked (step 1406) whether all the views have been considered. If there are still views (N), the loop is incremented (step 1407) and we return to step 1403.
  • step 1408 of supplying the dataset to the AI which can then be trained during step 1409 depending on the application.
  • FIG.15 is a block diagram of a system 1500 for implementing one or more embodiments of the invention. Methods according to embodiments are computer-implemented.
  • the 1500 system includes a communication bus to which are connected:
  • a processing unit 1501 such as a microprocessor, called CPU;
  • RAM random access memory unit 1502
  • executable code of a method according to one embodiment of the invention as well as registers suitable for recording the variables and parameters necessary for the implementation of a method according to embodiments, the memory capacity of which can be extended by an optional RAM connected to an extension port for example;
  • ROM read only memory
  • the network interface 1504 can be a single network interface, or composed of a set of different network interfaces (eg, wired and wireless interfaces, or different types of wired or wireless interfaces). Data is written to the network interface for transmission or is read from the network interface for reception under the control of the software application running in the CPU 1501;
  • a graphical user interface unit 1505 for receiving inputs from a user or displaying information to a user;
  • an I/O 1507 input/output module to receive/send data from/to external systems such as a video source or a screen.
  • the executable code can be stored either in ROM 1503, or on the hard disk 1506, or on a removable digital medium such as a disk for example.
  • the executable code of the programs can be received by means of a communication network, via the network interface 1504, in order to be stored in one of the storage means of the communication system 1500, such as the disk hard 1506, before being executed.
  • the central processing unit 1501 is suitable for controlling and directing the execution of the instructions or parts of software code of the program or programs according to the embodiments of the invention, these instructions being stored in one of the aforementioned storage means. After power-up, the processing unit 1501 is capable of executing the instructions of the main RAM 1502 relating to a software application after these instructions have been loaded from the ROM program 1503 or from the hard disk (HD) 1506 for example. Such a software application, when it is executed by the central unit 1501, causes the execution of the steps of a method according to incarnations.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Computing Systems (AREA)
  • Multimedia (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Mathematical Physics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Library & Information Science (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Evolutionary Biology (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention porte sur un procédé d'annotation de données d'apprentissage pour une intelligence artificielle comprenant les étapes suivantes : - stocker, dans une base de données, un ensemble de données à annoter, - stocker, dans ladite base de données, au moins une première description d'une première facette de sélection de données dans ledit ensemble de données, ladite première description étant associée à une première tâche à faire exécuter par ladite intelligence artificielle, - sélectionner ladite première facette dans ladite base de données, -appliquer ladite première facette à des données dudit ensemble de données pour obtenir des premières données filtrées,- recevoir au moins une première annotation desdites premières données filtrées, et -stocker ladite première annotation dans la base de données en association avec ladite première facette.

Description

Titre de l'invention : PROCEDE D'ANNOTATION DE DONNEES D'ENTRAINEMENT
DOMAINE TECHNIQUE DE L'INVENTION
[0001] La présente invention concerne le domaine de l'apprentissage machine (ou « machine learning » en anglais). Plus particulièrement, la présente invention concerne l'annotation de données utilisées pour l'apprentissage machine ou l'évaluation de per- formances.
ARRIERE-PLAN TECHNIQUE
[0002] Dans le domaine de l'apprentissage machine, les modèles dit “supervisés” doivent être “entraînés” sur des ensembles de données annotées (dits “dataset”'). Il s'agit par exemple d'images, de vidéos ou autre. Ces datasets peuvent aussi être utilisés pour évaluer les performances des machines en comparant leurs prédictions sur les données brutes aux annotations.
[0003] Les données sont annotées par des concepts que l'on cherche à « apprendre » à des machines afin qu'elles soient capables de les prédire automatiquement sur des données (images, vidéos etc.) qui leur sont par la suite données en entrée.
[0004] Par exemple, dans le cas d'un problème de classification d'image où l'on cherche à reconnaître un objet, par exemple un type d'animal, présent dans une image, une image d'un « dataset » contenant un chat peut être annotée avec une étiquette (« label » en anglais) “chat”. Dans un dataset, une étiquette est ainsi une métadonnée associée à la donnée initiale qui va renseigner la machine, lors de la phase d'entraînement, sur le concept qu'elle doit y reconnaître.
[0005] Si en outre, dans un problème de détection, on cherche à connaître la position de l'objet dans l'image, il est possible d'annoter l'objet, en plus de l'étiquette « chat », avec une région (ou « boîte ») englobante qui délimite les extrémités du « chat ». Il se peut d'ailleurs qu'il y ait plusieurs fois le même objet dans l'image (c'est-à-dire plusieurs chats dans l'image), auquel cas plusieurs annotations « boîtes englobantes » peuvent être ajoutées au dataset. Comme pour l'étiquette « chat », l'étiquette « boîte englobante » est une métadonnée associée aux données initiales.
[0006] Enfin, pour un problème de segmentation, on peut par exemple même aller jusqu'à délimiter les objets (les « chats ») au pixel près.
[0007] Dans le cas d'une application pratique d'intelligence artificielle (ou « IA »), il y a souvent plusieurs niveaux de concepts à annoter.
[0008] Par exemple, dans le cas d'une application d'assistance à des techniciens venant raccorder une maison ou un immeuble à la fibre optique, on souhaite apprendre à une machine à vérifier qu'un certain nombre d'étapes ont bien été respectées par les techniciens sur la base de photographies prises par ces derniers.
[0009] L'une de ces étapes peut par exemple impliquer de mesurer la qualité du signal sortant de la fibre avec un mesureur de puissance optique ou « wattmètre ». Le technicien doit alors prendre une photographie du wattmètre indiquant à l'écran un chiffre représentant la qualité du signal. Si l'on se place du point de vue de l'application d'IA, il est naturel d'annoter les images en trois niveaux hiérarchiques.
[0010] Le premier niveau d'annotation pourrait être le contexte dans lequel est prise la photo. Par exemple, il s'agit de déterminer si la photographie représente la boîte de raccordement dans la cave, la boîte de sortie de fibre dans le lieu de vie ou du wattmètre. Il s'agit donc ici d'un problème de classification. On détermine ce qui se trouve sur les images.
[0011] Le deuxième niveau d'annotation pourrait être pour chaque contexte, d'annoter les informations à reconnaître. Dans le cadre du contexte ^wattmètre” , on souhaite par exemple d'annoter la position de l'écran pour lire le chiffre à l'écran. Il s'agit donc ici d'un problème de détection. On détermine où se trouve un objet sur les images.
[0012] Le troisième niveau d'annotation pourrait être, dans le cas de l'écran du wattmètre, l'annotation de la valeur indiquée à l'écran. Il s'agit d'un problème de reconnaissance automatique de caractère (ou « OCR »). On détermine un texte sur les images.
[0013] Ces trois niveaux d'annotation sont un exemple. En particulier, l'ordre dans lequel elles sont effectuées dépend fortement du cas pratique. Dans d'autres cas, on peut très bien commencer par un problème de détection, puis un problème de classification au second niveau.
[0014] On peut aussi prendre l'exemple de l'annotation de photographies de plateaux repas. L'objectif est d'entraîner une application d'IA permettant la facturation automatique en restaurant d'entreprise. Sur la base d'une photographie d'un plateau repas, l'IA peut déterminer le prix de ce qu'il contient.
[0015] Dans cet exemple, les différents niveaux d'annotation peuvent être les suivants.
[0016] Le premier niveau d'annotation peut par exemple être l'annotation de boîtes en- globantes autour des différents plats et un label en fonction du type de plat. Il s'agit ici d'un problème de détection suivi d'un problème de classification. On détermine où se trouve un objet puis on détermine le type de cet objet (par exemple une entrée, un plat, un dessert etc.).
[0017] Le second niveau d'annotation peut par exemple être, pour chaque type de plat, l'annotation fine de la nature du plat (par exemple pour le type « entrée », il peut s'agir de salade de carotte, terrine, etc.).
[0018] Il apparaît ainsi que l'annotation des données se fait classiquement de manière hié- rarchique et définit un arbre (techniquement, la structure sous-jacente est une forêt car il peut y avoir plusieurs racines qui donnent lieu à plusieurs arborescences d'annotation). L'arbre n'est pas nécessairement régulier. Il peut y avoir peu de niveau de profondeur d'un côté et beaucoup de l'autre.
[0019] La pratique standard de l'état de l'art est de constituer autant d'ensembles de données que de nœuds dans l'arbre. Notamment, les images sont recadrées (“ cropped” en anglais) autour des objets d'intérêt pour normaliser les données et faciliter le processus d'apprentissage des IA.
[0020] Par exemple, les images du dataset de troisième niveau dans l'exemple du rac- cordement de la fibre (la lecture de la valeur du wattmètre) seraient toutes recadrées pour que l'écran du wattmètre couvre la quasi-totalité de l'image. En fait, l'image serait typiquement recadrée en utilisant la boîte englobante du deuxième niveau d'annotation (pour détecter la présence de l'écran).
[0021] Dans le cas où il y aurait plusieurs boîtes dans l'image (exemple du plateau repas), chaque boîte sur une image à un niveau donné produit plusieurs images dans les niveaux inférieurs.
[0022] Cette solution a l'avantage d'être conceptuellement simple. Elle est motivée par les besoins techniques des IA à entraîner. On dispose ainsi d'autant d'ensembles de données que de modèles à entraîner, et on annote précisément dans chaque ensemble de données la liste des informations que l'IA doit savoir reconnaître.
[0023] Cependant, cette solution a de très nombreux inconvénients.
[0024] Premièrement, cette solution ne permet pas de propager facilement les changements d'annotation, notamment dans le cas de la correction d'erreurs initiales d'annotation. Par exemple, dans le cas des plateaux repas, si une assiette était classée comme ini- tialement étant un plat principal, elle aura été injectée dans l'ensemble de données de niveau 2 correspondant aux “Plats Principaux” . Cependant, s'il s'agit en réalité, par exemple, d'une entrée et que ce cela est corrigé dans l'ensemble de donnée de niveau 1 rassemblant tous les plateaux repas, la méthode de l'état de l'art qui décompose le problème en différents ensemble de données séparés ne va pas refléter ces changements. Il faudra ainsi penser à manuellement supprimer l'image de l'ensemble de données de niveau 2 “Plats Principaux” pour la mettre dans “Entrées”.
[0025] Deuxièmement, les difficultés énoncées précédemment peuvent être partiellement soulagées avec des scripts informatiques responsables de vérifier l'intégrité du dataset, voir d'automatiser certaines tâches comme par exemple le recadrage et le filtrage des images. Ces scripts sont implémentés de manière ad-hoc et sont la plupart du temps peu voire pas testés, ce qui contribue à augmenter les risques d'erreurs.
[0026] Enfin, dans les cas où les annotations portent sur un grand nombre de classes, l'annotation d'un ensemble de données en suivant la méthode une “classique” de l'art antérieur est difficile car il faut avoir en tête l'ensemble des classes disponibles pour annoter sans faire d'erreur.
[0027] Les capacités de l'intelligence artificielle dépendent grandement de la qualité du dataset d'entrainement initial. On voit donc que la qualité des annotations est un problème majeur rencontré dans le domaine de l'apprentissage machine.
[0028] Or, ces datasets comportent parfois un nombre d'erreurs beaucoup trop important pour permettre un entrainement efficace de l'intelligence artificielle. Il est possible de prévoir des mécanismes de correction de l'intelligence artificielle, mais cela coûte en ressources et peut aussi nécessiter un certain temps avant qu'elle atteigne le niveau de performances attendu. Cela peut retarder grandement un déploiement à l'échelle in- dustrielle.
[0029] Comme cela a été présenté ci- avant, l'annotation et la génération des datasets se fait très souvent de manière hiérarchique. Ceci implique qu'une erreur d'annotation peut se propager très profondément dans l'arbre d'annotation. Une fois l'erreur propagée, il est pratiquement impossible de revenir en arrière, sauf à ré-annoter entièrement le dataset, ce qui est en pratique inenvisageable. On peut alors au mieux corriger une erreur d'annotation à un niveau mais pas aux niveaux inférieurs, ce qui n'améliore pas réellement la qualité du dataset puisque cela introduit des incohérences.
[0030] Ainsi, il existe un besoin pour améliorer l'annotation des datasets utilisés dans la conception de machines utilisées dans les applications d'intelligence artificielle. La présente invention s'inscrit dans ce contexte.
Résumé de l'invention
[0031] Un premier aspect de l'invention concerne un procédé d'annotation de données d'apprentissage pour une intelligence artificielle comprenant les étapes suivantes : stocker, dans une base de données, un ensemble de données à annoter, stocker, dans ladite base de données, au moins une première description d'une première facette de sélection de données dans ledit ensemble de données, ladite première description étant associée à une première tâche à faire exécuter par ladite in- telligence artificielle, sélectionner ladite première facette dans ladite base de données, appliquer ladite première facette à des données dudit ensemble de données pour obtenir des premières données filtrées, recevoir au moins une première annotation desdites premières données filtrées, et stocker ladite première annotation dans la base de données en association avec ladite première facette.
[0032] Par exemple, ladite base de données comporte une pluralité de descriptions d'une pluralité de facettes de sélection de données dans ledit ensemble de données et ladite première description comporte un lien hiérarchique vers une deuxième des- cription d'une deuxième facette de données dans la base de données, ladite première facette est appliquée à des deuxièmes données filtrées obtenues par ap- plication de ladite deuxième facette à des données dudit ensemble de données.
[0033] Par exemple encore : ladite deuxième facette porte sur une pluralité de sous-régions dans ledit ensemble de données, et la première facette est appliquée sur chaque région sur laquelle porte la deuxième facette.
[0034] Ces sous-régions sont des sous-parties des données dans ledit ensemble de données.
[0035] Selon des modes de réalisation : des annotations sont associées à certaines desdites régions sur lesquelles porte ladite deuxième facette ainsi qu'à ladite deuxième facette, et la première facette est appliquée sur chaque région portant une annotation associée à la deuxième facette.
[0036] Par exemple, la description de la première facette comporte une condition de filtrage appliquée aux annotations associées auxdites régions ainsi qu'à ladite deuxième facette et dans lequel la première facette n'est appliquée que pour les régions pour lesquelles ladite condition de filtrage est vérifiée.
[0037] Selon des modes de réalisation, ladite condition de filtrage est associée aux régions annotées par ladite deuxième facette et dans lequel la première facette n'est appliquée que sur les données issues d'un recadrage par ces régions et pour lesquelles la condition est vérifiée.
[0038] Selon des modes de réalisation, ladite annotation génère la définition d'une région dans ledit ensemble de données, ladite région est stockée en base de donnée en relation avec la région ayant servi au recadrage de la donnée annotée et ladite annotation est stockée dans ladite base de donnée en relation avec ladite première facette et ladite région.
[0039] Selon des modes de réalisation, ladite annotation ne crée pas de nouvelle région et dans lequel ladite annotation est stockée dans ladite base de données en relation avec ladite première facette ainsi que la région ayant servi au recadrage de la donnée annotée.
[0040] Le procédé peut en outre comporter une étape d'affichage desdites premières données filtrées pour un utilisateur, ladite annotation étant reçue de la part dudit uti- lisateur.
[0041] Alternativement, lesdites premières données filtrées sont fournies en entrée à un module d'intelligence artificielle mettant en œuvre ladite tâche, ladite annotation étant reçue de la part dudit module.
[0042] Un deuxième aspect de l'invention concerne un procédé d'apprentissage machine, pour l'exécution d'une tâche par une intelligence artificielle, comportant les étapes suivantes : accéder à une base de données comportant un ensemble de données et au moins une définition d'au moins une facette de sélection de données dans ledit ensemble de données, ladite une définition comportant en outre au moins une annotation associée à ladite facette, appliquer ladite facette de sélection de données audit ensemble de données pour obtenir des premières données filtrées, stocker lesdites premières données filtrées dans une mémoire de données d'apprentissage annotées, associer lesdites premières données filtrées aux annotations exécuter ladite tâche par ladite intelligence artificielle.
[0043] Par exemple, ladite annotation est générée selon un procédé selon le premier aspect de l'invention.
[0044] Un troisième aspect de l'invention concerne un dispositif comprenant une unité de traitement configurée pour la mise en œuvre d'étapes selon un procédé selon le premier et/ou le deuxième aspect(s).
FIGURES
[0045] [fig-1] La [fig.1] illustre l'annotation de données pour une vue racine selon des modes de réalisation.
[fig.2] La [fig.2] illustre l'annotation de données pour une vue enfant créatrice de régions selon des modes de réalisation.
[fig.3] La [fig.3] illustre un contexte d'utilisation l'annotation de données pour une vue enfant non créatrice de régions selon des modes de réalisation.
[fig.4] La [fig.4] illustre le fait qu'une donnée n'est pas annotée par une vue enfant lorsque la condition de celle-ci n'est pas satisfaite selon des modes de réalisation.
[fig.5] La [fig.5] illustre schématiquement une interface d'annotation selon des modes de réalisation.
[fig.6] La [fig.6] illustre schématiquement une interface de statistiques d'annotation selon des modes de réalisation.
[fig.7] La [fig.7] illustre schématiquement une interface d'accès à des images non annotées selon des modes de réalisation.
[fig.8] La [fig.8] illustre schématiquement un processus d'annotation selon des modes de réalisation.
[fig.9] La [fig.9] illustre schématiquement la structure d'une base de données selon des modes de réalisation.
[fig.10] La [fig.10] illustre schématiquement un exemple d'annotation d'images d'une application d'assistance technique à un raccordement de fibre selon des modes de réalisation.
[fig.11] La [fig.11] illustre schématiquement un procédé d'annotation selon des modes de réalisation.
[fig.12] La [fig.12] illustre schématiquement un procédé d'annotation selon des modes de réalisation.
[fig.13] La [fig.13] illustre schématiquement une annotation selon des modes de réa- lisation.
[fig.14] La [fig.14] illustre schématiquement une utilisation d'annotations produites selon des modes de réalisation.
[fig.15] La [fig.15] illustre schématiquement un dispositif selon des modes de réa- lisation.
DESCRIPTION DETAILLEE DE L'INVENTION
[0046] Dans ce qui suit, des modes de réalisation sont décrits qui offrent une annotation de données de manière hiérarchique. Ils permettent par exemple la conception d'applications de reconnaissance d'images ou de vidéos basées sur de l'apprentissage machine. L'invention n'est pas limitée à ce type d'application et d'autres types de données peuvent être utilisées.
[0047] Les modes de réalisation de l'invention permettent de manipuler et stocker le caractère hiérarchique des concepts annotés, d'annoter plus efficacement et de découpler la notion de modèle d'apprentissage machine de la notion d'ensemble de données (ou « dataset » en anglais).
[0048] Selon l'invention, les modes de réalisation tirent avantage de la structure hié- rarchique des données à annoter pour faciliter l'annotation alors même que cette structure hiérarchique est une source de problème dans l'art antérieur.
[0049] Il devient ainsi possible de découper un travail d'annotation en plusieurs sous-tâches indépendantes.
[0050] Les modes de réalisation permettent de répondre au problème de la propagation d'erreur dans les modèles de l'art antérieur. Ils permettent par exemple de prendre en compte automatiquement les changements de classes pour les répercuter automa- tiquement.
[0051] Les modes de réalisation permettent en outre d'annoter des données sans provoquer une inflation des celles-ci-au fur et à mesure de l'annotation. La phase de génération des données effectivement annotées peut-être reportée à une phase d'entraînement effective.
[0052] Comme cela est décrit en détail dans ce qui suit, l'annotation selon les modes de réa- lisation prend en compte la structure hiérarchique des annotations à effectuer. Un recadrage automatique des données autour des régions pertinentes à annoter peut être effectué pour l'annotation sans générer de nouveaux sous-ensembles de données. Il est aussi possible de filtrer les images à annoter pour n'afficher que les régions de données pertinentes.
[0053] Dans ce qui suit, les principes applicables aux différents modes de réalisation de l'invention sont tout d'abord présentés.
[0054] Contrairement aux techniques d'annotation de l'art antérieur, les modes de réalisation de l'invention ne vont pas s'attacher à créer des « sous datasets » au fur et à mesure des annotations faites sur les données du datasets. Ainsi, l'inflation du dataset par le processus d'annotation qui est la source de la propagation des erreurs dans l'art antérieur n'est pas reprise.
[0055] Au contraire, le dataset initial va être conservé et l'on va créer un système de construction dynamique de datasets (les «facettes » ou « vues ») auquel vont être associées les annotations. Ainsi, il sera possible de faire toute manipulation, y compris des corrections sur ce système de construction, sans toucher au données du dataset. Les « sous datasets » seront générés à la demande, selon l'usage souhaité (par exemple l'entraînement d'une IA) une fois le système de construction validé.
[0056] Le contexte de mise en œuvre des modes de réalisation de l'invention est ainsi le suivant.
[0057] On considère un ensemble de données non structurées à annoter pour permettre l'entraînement d'une intelligence artificielle sur un certain nombre de tâches.
[0058] Des « données » (non annotées) font référence à tout type de donnée qui peut ty- piquement être produite par un capteur, un appareil de capture ou un appareil de saisie manuelle. Il peut s'agir d'une image, d'un flux vidéo, d'un nuage de point, d'une image 3D faite de voxels, d'un flux sonore, d'un texte, d'une série temporelle, etc.
[0059] Des annotations sont les informations supplémentaires liées à une donnée et relatives à son contenu. Par exemple la position d'un objet dans une image et/ou sa « classe » (ou « type »).
[0060] Une « tâche » désigne toute action d'une machine lui permettant de prédire automa- tiquement les annotations d'une donnée, ou un sous-ensemble des annotations. On peut citer un grand nombre de tâches. Quelques exemples sont cités ci-après.
[0061] Pour une tâche de classification, l'annotation à prédire est une catégorie d'objet, autrement appelée une « classe », parmi une liste prédéterminée de classes possibles. Par exemple, étant donné une photo d'animal, on cherche à savoir de quel animal il s'agit.
[0062] Pour une tâche de détection, l'annotation à prédire est une liste des objets présents dans l'image parmi une liste des classes d'intérêt. Chaque objet prédit doit indiquer une délimitation simple de l'objet, typiquement sous forme de boîte englobante ainsi que sa classe. Par exemple, étant donné une vidéo capturée par une voiture autonome, on cherche à savoir où sont tous les véhicules, les piétons, les cyclistes, etc.
[0063] Pour une tâche de segmentation, l'annotation à prédire est la même que pour une tâche de détection, mais les objets doivent être délimités au pixel près.
[0064] Pour une tâche d'OCR (acronyme d'« Optical Character Recognition »), il s'agit de prédire le texte présent dans une image. Par exemple, lire un numéro de plaque d'immatriculation à partir d'une photo de plaque.
[0065] Pour une tâche d'estimation de pose, il s'agit de prédire la “pose” d'un objet dé- formable. Typiquement, des parties clés de l'objet sont identifiées au préalable et reliées par un arbre. Il s'agit alors de prédire la position des différents nœuds de l'arbre s'ils sont visibles ou d'indiquer qu'ils sont invisibles. Par exemple, dans le cas de l'estimation de la pose d'une personne, on cherche typiquement à localiser la tête, les mains, les pieds, etc. de chaque personne présente dans l'image.
[0066] Pour une tâche de régression, il s'agit de prédire un nombre où un vecteur (i.e. une liste de N nombres, N étant connu au préalable). Par exemple, il s'agit de prédire l'âge d'une personne étant donné la photo d'un visage.
[0067] Cette liste de tâches est bien entendu non exhaustive mais permet de se rendre compte de la variété de tâches que l'on peut demander à une IA et donc la variété des annotations possibles dans un dataset.
[0068] Lorsque ces différentes tâches contribuent à la résolution d'un même problème en s'appuyant sur un ou plusieurs algorithmes de reconnaissance automatique, il est courant que ces tâches soient organisées de manière hiérarchique.
[0069] La relation de hiérarchie entre une tâche A et une tâche B peut par exemple ap- paraître lorsque le besoin d'annoter des données pour la tâche B dépend de l'annotation de ces données pour la tâche A. Il s'agit par exemple du cas où le besoin d'annoter pour la tâche B dépend de la classe d'objet indiquée dans A. Dans l'exemple de la vérification de raccordement donné en introduction, il s'agit par exemple de l'annotation de l'écran du wattmètre qui n'est pertinente que dans le cadre où l'image montre effectivement un wattmètre et a été annotée comme telle dans le premier niveau d'annotation. Il s'agit donc d'être capable de “filtrer” les régions à annoter pour la tâche B en fonction d'une certaine condition sur l'annotation de la tâche A.
[0070] La relation de hiérarchie peut aussi apparaître lorsque la tâche B consiste à annoter les mêmes régions de données que celles définies par la tâche A. Dans l'exemple donné en introduction concernant les plateaux repas, il s'agit par exemple d'annoter la nature du plat sur l'image issue du recadrage de l'image d'origine par la région définie dans la tâche A.
[0071] Les relations de hiérarchie peuvent apparaitre pour tout autre raison qui induit le fait que l'annotation pour la tâche A peut être directement réutilisée pour définir le besoin d'annotation ou simplifier le processus d'annotation pour la tâche B.
[0072] Comme mentionné ci-dessus, il est courant d'annoter une même région d'une donnée dans différentes tâches. Par exemple, c'est la cas lorsqu'une tâche de classification s'attache à annoter la classe détaillée d'un objet créé lors d'une tâche de détection en amont. On appelle région une sous partie d'une donnée définie par ses valeurs ex- trémales sur les différents axes de la donnée (x, y, z pour ce qui est de données spatiales et/ou t pour le cas de vidéo). Lorsque l'axe temporel est impliqué (par exemple pour une vidéo), la position spatiale (i.e. en x, y, z) peut varier pour chaque valeur de t entre t_min et t_max. L'intérêt d'une région est de pouvoir recadrer une donnée produire une nouvelle (sous-)donnée à annoter.
[0073] Conformément aux modes de réalisation décrits dans ce qui suit, afin de représenter les relations hiérarchiques entre les tâches et les régions, la notion de ‘facette” est utilisée. Chaque tâche d'annotation se voit attribuer une unique facette qui lui est propre (i.e. une tâche est liée à une unique facette et vice versa).
[0074] Une facette s'entend par analogie avec le terme de facette dans le domaine de la recherche d'information basée sur une classification à facette, qui donne aux uti- lisateurs la capacité de filtrer les données en fonction de la facette sélectionnée. Dans ce qui suit, et sans perdre de généralité, le terme de « vue » est utilisé.
[0075] En plus d'être liée à une tâche, une vue peut être rattaché hiérarchiquement à une autre vue, dite « vue parente » ou « parent » (ou inversement une « vue enfant » ou « enfant »). Une vue n'ayant pas de vue parente est dite « vue racine ».
[0076] Lorsqu'une vue est une vue enfant, elle définit une « condition de filtrage » sur l'annotation de la vue parente, ou « condition ». Les données de la vue parente vérifiant la condition définissent la vue enfant. Ceci permet de créer des sous datasets.
[0077] Un processus d'annotation peut avoir plusieurs vues racines. Formellement, la relation de parenté entre les vues induit une structure de forêt au sens d'un ensemble d'arbre disjoints comme cela est défini en théorie des graphes.
[0078] Comme cela est décrit dans ce qui suit, les vues telles que définies ci- avant permettent, dans les modes de réalisation de l'invention, de filtrer et recadrer les régions produites par la vue parente pour présenter à l'utilisateur qui effectue l'annotation, des données valides et centrées sur les régions d'intérêt. Comme cela est expliqué dans ce qui suit, cela permet d'annoter plus efficacement. Cela permet aussi de manipuler des données à la volée dans la phase d'annotation et de réserver la phase de génération des datasets annotés pour la phase d'entraînement de l'IA.
[0079] Une définition plus formelle des vues est donnée ci-après.
[0080] On définit l'ensemble de toutes les régions possibles R et on associe une région racine ri, o ∈ R à chacune des données di ∈ D du dataset. Ainsi, chaque donnée a au moins une vue racine. [0081] On définit la fonction de recadrage crop : D X R → D qui prend en entrée une donnée d et une région f et renvoie la sous-donnée issue du recadrage de d par r . Le fait de recadrer par une région racine ne modifie pas la donnée :
Figure imgf000013_0004
[0082] On note { vj | j = 1, . . . , n | l'ensemble des n vues et p : N N (avec l'ensemble des nombres naturels) la fonction parent telle que p(J) = 0 si vj est une vue racine et p(j) = k si est la vue parent de vj.
[0083] On note annotated ( j , r ) e { 0,1 } la fonction qui définit si la région r est annotée pour la vue vj (on pose par ailleurs
Figure imgf000013_0005
annotated(0, r) = 1), et A j l'ensemble des annotations possibles pour vj (la forme exacte de A . dépend du type de tâche associée à v j : classification, détection, etc...).
[0084] On note aussi la fonction qui permet de récupérer les annotations d'une
Figure imgf000013_0006
région déjà annotée dans la vue vj.
[0085] L'ensemble des régions sur lesquelles portent les annotations d'une région r par la vue vj est noté regions(j , r).
[0086] Par exemple, dans le cadre d'une tâche de détection regions ( j , r ) correspond à l'ensemble des régions définies par les boîtes englobantes nouvellement annotées. Si aucune région n'est créée (comme dans le cas d'une tâche de classification), alors on a regions(J , r) = { r) . Pour gérer le cas des vue racine, on pose regions(O, ri, o) = { ri, o} .
[0087] On note C . R {0,1 } la fonction qui vaut 0 ou 1 selon que la condition de filtrage de la vue vj est valide ou non (pour toute vue racine on définit
Figure imgf000013_0002
[0088] On appelle Ri, j l'ensemble des régions à annoter pour la vue vj sur les données On pose Ri, 0 = { ri, o}, telle que a . et
Figure imgf000013_0001
Figure imgf000013_0003
[0089] Les données présentées à l'annotation pour la vue vj sont l'ensemble des données recadrées par les régions à annoter, c'est à dire
Dj = { crop ( di, r) | di ∈ D et r ∈ Ri,j } . Ces données peuvent ensuite être annotées de la même manière que l'état de l'art, c'est à dire en considérant Dj comme un flux de données à annoter qui peut être pris isolément du reste du processus d'annotation.
[0090] Ainsi, l'interaction d'une vue avec sa vue parente (à travers les notions de région et de condition, définies plus haut) est le moyen qui permet de mettre en œuvre les mani- pulations nécessaires lors de l'annotation afin d'accélérer et de fiabiliser le processus d'annotation de la tâche à laquelle elle est rattachée. Cela permet de s'affranchir de l'inflation des données lors de la phase d'annotation selon les techniques de l'art antérieur.
[0091] En d'autres termes, la création de la notion de « vue » permet une annotation dynamique des données ce qui a pour conséquence de ne pas créer des sous datasets au fur et à mesure de l'annotation. Selon les modes de réalisation décrits ci- après, il est possible d'annoter les données sans modifier les données en elle-même. Il est ainsi possible de modifier toute annotation à tout moment et ce avec la possibilité qui n'existe pas dans l'art antérieur de répercuter ces modifications aussi profondément que l'on souhaite puisque la liste des données à annoter pour une tâche donnée et le recadrage sur la zone d'intérêt sont calculées à la volée en fonction des annotations déjà présentes dans la tâche parente.
[0092] Conformément aux définitions et formules énoncées ci-avant, on sait définir for- mellement les données à présenter à un utilisateur (ou un processus automatique) à partir d'un ensemble initial, pour l'annotation. Comme décrit dans ce qui suit, dans le processus d'annotation, au lieu de faire des liens directs entre données et annotations, il s'agit ici de faire des liens entre annotations et formalisation de la manière d'obtenir les données présentées à l'utilisateur (ou au processus) à partir des données initiales. Cette association permet d'améliorer le processus d'annotation.
[0093] Dans ce qui suit, on illustre les équations formelles données ci-avant pour différents cas de figure.
[0094] En référence à la figure 1, on illustre le cas d'une vue racine vj 101 où la donnée présentée à l'annotation est exactement la donnée brute de l'ensemble de données à annoter. En effet, la région à annoter est nécessairement la région racine 103 qui englobe toute la donnée di102. Cela se retrouve via le formalisme ci-dessus car et donc la donnée présentée à l'annotation est
Figure imgf000014_0001
La vue racine 101 se comporte donc comme une tâche
Figure imgf000014_0002
d'annotation “ standard” qui suivrait les pratiques de l'état de l'art selon lesquelles on ajoute les annotations 104 à l'ensemble de données D pour la tâche liée à vj. La différence est que l'annotation est rattachée à la région racine 103 et non directement à la donnée 102. Dans le cas où il y a plusieurs vues racines, toutes les annotations sont rattachées à la même région racine 103.
[0095] On considère dans ce qui suit, des cas où les régions à annoter pour une vue B sont cette fois celles issues d'une annotation de la vue A.
[0096] Dans l'exemple de la [fig.2], on commence par appliquer une vue parente A 200 (parente de la vue B 202) sur une donnée 203 issue l'ensemble de données à annoter. On suppose que cette vue parente A est créatrice de nouvelles régions A 204 et 205 (par exemple dans le cas d'une tâche de détection) qui reçoivent respectivement des annotations 206 et 207. On suppose que la vue A s'applique sur une région racine 208 pour simplifier la figure (le procédé serait similaire pour le cas d'une une région non racine).
[0097] On suppose que les annotations de la région 205 (trait plein) vérifient une condition B alors que celles de la région 204 ne la vérifient pas (trait en pointillés). Ainsi seule la donnée 203 recadrée par la région A 205 vérifiant la condition B sera présentée en vue de l'annotation selon la vue B. La donnée issue d'un recadrage par la région 204 n'est pas présentée.
[0098] De manière générale, les données à annoter pour la vue B 202 sont les données initiales recadrées par les régions annotée par la vue A 200 dont l'annotation vérifie la condition B. Après l'application de la vue B 202, l'annotation 209 est associée à la région 205 qui a servi au recadrage de la donnée annotée.
[0099] L'exemple de la [fig.2] est très simplifié et ne représente qu'une seule donnée 203 initiale. Si par exemple la vue A 200 créé deux régions sur un première données et trois régions sur une deuxième donnée, alors il y aurait 5 données à annoter pour la vue B 202, issues des recadrages de chacune des 5 régions produites par la vue A 200.
[0100] On voit donc dans l'exemple de la [fig.2] que l'ensemble des données initiales forme toujours un tout sans que rien ne lui soit ajouté. C'est simplement différentes manières de le « voir », les vues, qui sont créés au fur et à mesure et les annotations sont associées à ces vues et aux régions qui les portent, et non directement à des données.
[0101] Selon l'art antérieur, au lieu de conserver un ensemble unique de données 203, on aurait créé deux sous-ensembles de données correspondant aux deux tâches des vues A et B. Pour la vue A, qui pourrait par exemple être une vue de détection, le dataset com- porterait la donnée 203 recadrée par la région 208, annotée par deux régions (par exemple des boîtes englobantes et leurs classes) 204+206 et 205+207. Pour la vue B, qui pourrait être une vue de classification, le dataset comporterait la donnée 203 recadrée par la région 205 et annotée par 209.
[0102] Selon l'invention, la donnée 203 n'est pas modifiée et les annotations ne lui sont pas adjointes directement. On crée plutôt une représentation des vues A et B, ainsi que des régions et on associe les annotations à ces régions. Durant le processus d'annotation, il n'y a pas de création de nouveaux sous-ensembles de données. Seules les vues sont utilisées pour générer les données à annoter et permettre à l'utilisateur (ou un processus automatique) de les annoter. Ces mêmes vues pourront servir à générer ef- fectivement les données annotées pour les donner en entrée à une IA en phase d'entraînement. Entre-temps, le stockage et le traitement des annotations est grandement facilité car la hiérarchie entre les annotations est automatiquement conservée ce qui permet de fiabiliser le processus de mise à jour (modification ou sup- pression) des annotations.
[0103] Dans l'exemple de la [fig.3], la vue parente A n'est pas créatrice de nouvelles régions (par exemple dans le cas d'une tâche de classification). Dans ce cas l'annotation pour la vue B porte sur les mêmes régions que la vue A.
[0104] On commence par appliquer une vue parente A 300 (parente de la vue B 301) sur une donnée 302 issue de l'ensemble de données à annoter. Comme indiqué, cette vue parente A 300 n'est pas créatrice de nouvelles régions comme précédemment. On retrouve donc après l'application de la vue A 300, la même région 303. Cette région est associée à l'annotation 304. On suppose que la vue A s'applique sur une région racine 303 pour simplifier la figure (on pourrait considérer le cas d'une région qui ne l'est pas).
[0105] On suppose que les annotations 304 vérifient la condition de la vue B 301. La donnée à annoter pour la vue B 301 est alors la donnée initiale 302 recadrée par la région 303. C'est-à-dire celle déjà annotée par la vue A 300. Après l'application de la vue B 301, l'annotation 305 est associée à la région 303.
[0106] On voit donc dans l'exemple de la [fig.3] que comme pour la [fig.2], l'ensemble des données initiales forme toujours un tout sans que rien ne lui soit ajouté. C'est simplement différentes manières de le « voir », les vues, qui sont créés au fur et à mesure et les annotations sont associées à ces vues.
[0107] Selon l'art antérieur, au lieu de conserver un ensemble unique de données, on aurait créé deux sous-ensembles de données correspondant aux deux tâches des vues A et B. Pour la vue A, qui pourrait par exemple être une vue de classification, le dataset com- porterait la donnée 302 recadrée par la région 303 et annotée par 304. Pour la vue B, qui pourrait aussi être par exemple une vue de classification, le dataset comporterait la donnée 302 recardée par la région 303 et annotée par 305.
[0108] L'exemple de la [fig.4] est similaire à celui de la [fig.3] sauf que l'on considère cette fois que les annotations de la vue A 304 ne satisfont pas la condition B de la vue B.
[0109] Dans ce cas, la région des données ne sera pas présentée à l'utilisateur pour an- notation et aucune annotation ne sera ajoutée (l'annotation 305 est absente).
[0110] L'annotation de données selon les principes ci-dessus peut se présenter dans la forme décrite dans ce qui suit.
[0111] Un utilisateur peut par exemple accéder à une interface 500 d'un système d'annotation telle qu'illustrée par la [fig.5] . Cette interface permet d'afficher les vues et de manipuler les hiérarchies entre elles.
[0112] Ainsi, l'interface 500 comporte une zone d'action 501 comportant divers boutons 502 (ACT1), 503 (ACT2), 504 (ACT3). Par exemple ces boutons permettent à l'utilisateur de gérer l'ensemble de données de manière générale, par exemple en ajoutant des données, en visualisant une cartographie des vues, en supprimant des images, etc.
[0113] L'interface 500 comporte aussi une zone 505 d'affichage des vues racines. Ici, par souci de concision, une vue racine 506 (VI) est représentée. D'autres vues racines pourraient être présentes dans cette zone. Dans cette zone, un bouton 508 permet à l'utilisateur d'ajouter des vues racines.
[0114] L'utilisateur peut sélectionner une vue, par exemple 506, et une zone 509 similaire à 500 apparaît pour afficher les vues enfants de la vue sélectionnée. Par exemple, les vues 510 (Vl.l), 511 (V1.2), 512 (V1.3) dépendent de la vue 506 (VI) qui est donc une vue parente pour elles. Dans cette zone, un bouton 513 permet à l'utilisateur d'ajouter des vues dépendantes de la vue sélectionnée dans la zone 500. Par exemple, l'utilisateur sélectionne la vue 506, puis clique sur le bouton 513 pour créer une vue dépendante de la vue 506.
[0115] Le procédé continue de manière récursive aussi longtemps qu'il y a de profondeur dans l'arbre des vues. Par exemple, une zone 514 permet quant à elle d'afficher des vues dépendantes de la vue sélectionnée dans la zone 509 et un bouton 515 permet d'ajouter une vue dépendante à la vue sélectionnée. Dans l'exemple illustré, la vue 511 est par exemple sélectionnée mais ne contient pas de vue enfant. L'utilisateur clique alors sur le bouton 516 pour créer une première vue dépendante de cette vue sé- lectionnée.
[0116] Comme illustré par la [fig.6], lorsqu'il clique sur une vue de la [fig.5], l'utilisateur peut visualiser les statistiques liées à cette vue.
[0117] La [fig.6] illustre une interface 600 comprenant une zone d'action 601 avec un ensemble de boutons 602 (ACT4), 603 (ACT5), 604 (ACT6). Par exemple ces boutons permettent à l'utilisateur d'annoter des images, de corriger des annotations, d'ajouter des concepts à reconnaître, etc.
[0118] L'interface 600 comporte en outre une zone 605, avec un certain nombre de fenêtres permettant à l'utilisateur de gérer les images d'une vue. Par exemple, une fenêtre 606 (DISTRI IMG) donne accès à une distribution des images de la vue entre différentes utilisations (on peut retrouver le nombre de données d'entraînement, de données non annotées, ou autre). Cela permet de savoir à quelle utilisation sont destinées les images de la vue. Une fenêtre 607 (DISTR2 CNCPT) donne accès à une autre distribution concernant les concepts que la machine sera amenée à prédire. Pour chaque concept, on peut voir le nombre d'images qui y sont associées.
[0119] Une fenêtre 608 (IMG) peut donner accès au nombre d'images dans la vue. Une fenêtre 609 (CNCPT) donne accès au nombre de concepts associés à la vue.
[0120] L'un des boutons de la zone 601 peut donner accès à l'utilisateur aux images non annotées dans une interface 700 illustrée par la [fig.7] .
[0121] Cette interface 700 comporte une zone d'action 701 avec un certain nombre de boutons 702 (ACT7), 703 (ACT8), 704 (ACT9) permettant à l'utilisateur de faire un certain nombre d'actions. Ces boutons sont par exemple les mêmes que ceux de l'interface 600 ou peuvent être complétés par d'autres. Selon certains exemples, elle peut comporter un bouton ouvrant la possibilité à l'utilisateur d'annoter une image non encore annotée, grâce à une interface d'annotation permettant de réaliser une an- notation propre au type de tâche liée à la vue sélectionnée dans l'interface 600. Cette interface est conforme aux pratiques de l'état de l'art et n'est pas décrite ici. Cela dit, contrairement à l'état de l'art, elle s'applique non pas directement à la donnée annotée mais à la région d'intérêt comme décrit dans la [fig.8] ci-dessous.
[0122] L'interface 700 comporte en outre une zone 705 avec toutes les images 706 (IMG) non encore annotées. Par exemple, l'utilisateur sélectionne une image dans la zone en cliquant dessus et est redirigé vers l'interface d'annotation de l'image pour la tâche et la vue sélectionnée comme précédemment.
[0123] Avec des interfaces telles que présentées ci-avant, on peut voir que le processus d'annotation et totalement différent de celui de l'état de l'art. En effet, les données à annoter peuvent être affichées à l'utilisateur « à la volée » en fonction des différentes vues. On profite donc de la hiérarchisation des tâches, sans pour autant créer de nouvelles données à chaque annotation.
[0124] On peut donc annoter les données de manière automatique en fonction des vues parentes. La hiérarchie de vues sous forme d'arbre est donc différente d'une génération de données annotées comme selon l'art antérieur. Cette hiérarchie permet un affichage pour l'ajout d'annotation, non pas sur les données mais sur les régions produites par les vues parentes de la vue en cours d'annotation.
[0125] Le processus est présenté schématiquement dans la [fig.8]. L'utilisateur annote ty- piquement les données les unes après les autres. On décrit ici comment le flux de données à annoter est généré. En entrée on trouve le flux des régions annotées 803 (REG) par la vue parente de la vue sélectionnée pour l'annotation, ci-dessous appelée vue courante. Si la vue courante est une vue racine (i.e. elle n'a pas de vue parente), alors ce flux est constitué de toutes les régions racines. Ensuite, lors de l'étape 800 (FILTR), les régions sont filtrées par la condition à appliquer pour l'annotation selon la vue courante. En sortie, on retrouve alors les régions utiles 804 (REG_CHLD) pour l'annotation souhaitée. Lors de l'étape 801 (CROP), les données à annoter sont présentées, recadrées par les régions utiles 804. En sortie, on obtient ainsi le flux de données à annoter 805 (DAT) qui sont ensuite annotées lors de l'étape 802. Les an- notations sont rattachées à la région utile 804 et non à la donnée générée par le recadrage 805, si bien que cette dernière peut être supprimée une fois annotée. En sortie du processus on trouve le flux de région annoté pour la vue courante 806 (REG_ANNOT). C'est ce flux de régions annotées qui sera utilisé en lieu et place du flux 803 pour toutes les vues enfants de la vue courante. A la différence de l'art antérieur, on n'obtient pas directement un flux de données annotées, mais un flux de régions annotées, elles-mêmes liées à la donnée qui les porte et qui n'est pas dupliquée.
[0126] Le procédé présenté ci-avant est décrit dans le cas d'une annotation manuelle par un utilisateur humain. Cependant, l'annotation peut aussi être réalisée à la volée par un module d'annotation automatique. Dans ce cas, le processus de la [fig.8] reste valable. L'étape 802 est alors mise en œuvre par le module d'annotation. Le recadrage est toujours effectué pour présenter les données au module mais il n'est plus utile dans ce cas d'afficher le résultat. Ce mode de réalisation peut être utile dans les cas où une in- telligence artificielle est déjà suffisamment entraînée et donne des résultats suf- fisamment satisfaisants pour pouvoir convertir une prédiction en annotation lorsque le score de confiance est suffisamment élevé. On permet alors à l'intelligence artificielle de s'enrichir elle-même en lui donnant de nouvelles images annotées.
[0127] En pratique, les notions de données, vues, régions, annotations sont stockées en base de données. Lorsque l'utilisateur cherche à visualiser les données non annotées (voir la [fig.7] ), une requête à la base de données est effectuée pour obtenir (i) toutes les régions racines si la vue courante est une vue racine et (ii) toutes les régions déjà annotées dans la vue parente et qui satisfont la condition de la vue courante dans les autres cas.
[0128] A chaque annotation, un nouvel objet « annotation » est créé dans la base de données. Cet objet est lié à la vue qui l'a produit et à la région sur laquelle il porte.
[0129] Si la tâche liée à la vue ne crée pas de nouvelle région mais se contente d'enrichir la région passée en entrée (comme par exemple dans le cas de la classification) alors l'annotation nouvellement crée est liée à cette région et celle-ci est considérée comme annotée pour la vue courante. L'annotation devient alors disponible à l'annotation dans les vues enfants.
[0130] Si la tâche liée à la vue crée de nouvelles régions (comme par exemple dans le cas de la détection), ce sont ces nouvelles régions deviennent disponibles pour l'annotation dans les vues enfants. Pour des raisons pratiques, ces nouvelles régions mémorisent leur région parente (voir l'étape 1305 écrite ci-dessous) dans la base de données, notamment pour permettre la suppression des régions et annotations enfantes en cascade comme expliqué ci-dessous.
[0131] Le stockage des annotations, non pas en lien avec des données mais en lien avec les vues hiérarchiques permet de faire des corrections d'annotation de manière très simple. Par exemple, en cas de suppression d'une région, cela permet de s'appuyer sur le mécanisme de suppression en cascade d'une base de données. Toutes les régions et an- notations qui héritent de cette région supprimée dans les vues enfants sont automa- tiquement supprimées.
[0132] En outre, lorsqu'on modifie une annotation, une des difficultés d'annotation consiste à bien vérifier si la condition de filtrage des vues enfants n'est pas violée, et le cas échéant à correctement supprimer les annotations devenues invalides. Par ailleurs, une région stocke la vue qui l'a créée afin de permettre de supprimer efficacement toutes les régions et annotations issues d'une vue donnée et de ses enfants lorsque cette vue est supprimée.
[0133] La [fig.9] illustre une base de données selon des modes de réalisation selon une sché- matisation de type UML.
[0134] Comme on peut le constater, à la fois les données 901 et les vues (avec leurs conditions) 902 sont liées au dataset 900 auquel elles appartiennent. Les régions 903 sont quant à elles liées aux données 901 et aux vues (avec leurs conditions) 902 qui les portent. Comme une vue doit stocker une référence à sa vue parente (cette référence est nulle dans le cas d'une vue racine), la table des vues est reliée à elle-même dans la [fig.9]. De la même manière, les régions peuvent stocker leur région parente comme expliqué ci-avant. Enfin, les annotations 904 héritent à la fois des régions 903 et des vues et conditions puisque les annotations sont liées à l'une et l'autre.
[0135] En comparaison, un schéma du même type est aussi représenté sur la figure 9 pour une base de données d'annotation selon l'art antérieur. Cette fois, la structure est beaucoup plus simple puisque les annotations 907 sont liées aux données 906 qui sont elles-mêmes liées au dataset 905. La base de données selon l'art antérieur ne dispose pas de la notion de vue qui permet la création à la volée des données à annoter en fonction des annotations de l'étape précédente lorsque la tâche d'annotation est hié- rarchique.
[0136] L'annotation d'images dans le cas d'une application d'assistance à des techniciens venant raccorder une maison ou un immeuble à la fibre optique selon des modes de réalisation est maintenant décrite en référence à la [fig.10].
[0137] On suppose tout d'abord une première vue racine vl de classification 1000 (VI) nommée “Contexte” avec deux classes (ou type) : “Wattmètre” et “Armoire”. Cela permet de différencier deux types de photos prises par le technicien : (i) soit une photo de l'appareil servant à mesurer la puissance du signal appelé wattmètre (il va alors s'agir de dire si la puissance du signal affiché à l'écran est conforme au seuil minimum), (ii) soit une photo de l'armoire de raccordement des fibres optiques (il va alors s'agir de dire si les différentes zones de raccordement sont valides).
[0138] On suppose aussi une vue v2 de détection 1001 (V2) nommée “ Ecran” ayant pour parent la vue vl 1000 et une seule classe (ou type) “Ecran". Son rôle est de permettre de localiser l'écran du wattmètre pour le lire. Cette vue 1001 possède une condition. Il faut que la région soit annotée “Wattmètre” dans la vue parente pour qu'une annotation soit associée à une image de cette vue.
[0139] On suppose aussi une vue v3 d'OCR 1002 nommée “ Qualité Signal” ayant pour parent la vue v2 1001 dont le but est de permettre d'annoter le texte à l'écran. Cette vue ne possède pas de condition, c'est-à-dire que V r R, c3 ( r ) = 1 (selon le formalisme décrit ci-avant).
[0140] Une vue v4 de détection 1003 nommée “Raccordement” ayant pour parent la vue vl 1000 et deux classes (ou type) “OK” et “KO”. Son but est d'identifier les zones de rac- cordement conformes ou non. Cette vue possède une condition. Il faut que la région soit annotée “Armoire” dans la vue parente pour qu'une annotation soit associée à une image de cette vue.
[0141] On décrit maintenant le lien entre données (en l'occurrence des images dans ce cas) et régions 1004, annotations 1005 et vues 1006 pour deux images 1007 et 1008. Chaque donnée porte des régions organisées sous forme d'arbre à partir d'une région racine qui englobe toute la donnée. Une annotation est rattachée à une région et une vue. En fonction du type de vue, l'annotation peut être une classe, du texte, etc. Chaque vue possède un type et éventuellement une condition.
[0142] L'image 1007 représente un wattmètre. On définit alors une première région 1009 qui est une région racine. On définit aussi une sous-région 1010 autour de l'écran du wattmètre.
[0143] La région 1009 est ainsi annotée 1011 selon la classe « Wattmètre ». La région 1010 reçoit quant à elle deux annotations : l'une est la classe « Ecran » 1012 et l'autre est le texte reconnu par OCR sur l'écran 1013 par exemple « -4,6 dB ». Les annotations 1011 , 1012, 1013 sont ainsi respectivement associées aux vues 1000, 1001, 1002.
[0144] L'image 1008 représente une armoire de raccordement. On définit alors une première région 1014 qui est une région racine. On définit aussi une sous-région 1015 et une sous-région 1016 qui correspondent à deux zones différentes de l'armoire.
[0145] La région 1014 est ainsi annotée 1017 selon la classe « Armoire ». La région 1015 reçoit quant à elle une annotation « OK » 1018 car elle comporte une zone de rac- cordement conforme. La région 1016 reçoit une annotation « KO » 1019 car elle comporte une zone de raccordement non conforme. L'annotation 1017 est associée à la vue v 1 1000 car la présence de l'armoire est une annotation de « Contexte ». Les an- notations 1018 et 1019 sont toutes les deux associées à la vue v4 1003 car le bon ou mauvais raccordement est une annotation de « Raccordement ».
[0146] Dans la formalisation qui précède, les conditions sont appliquées aux annotations de la vue parente en général. Les exemples qui précèdent montrent qu'il peut notamment être important de pouvoir définir des conditions sur les classes annotées dans la région parente. On décrit maintenant des variantes selon des modes de réalisation. [0147] La condition d'une vue vj peut par exemple porter sur la classe annotée dans la vue parente (si celle-ci est unique, voir paragraphe ci-dessous pour le cas multi-classes) pour restreindre l'annotation de vj à certaines classes uniquement. Cela permet par exemple de spécialiser des vues à certains contextes de prise de vue ou d'objets, ty- piquement afin de structurer et simplifier le travail d'annotation afin d'avoir moins de classes (ou types) à annoter.
[0148] Appelons la fonction de classe qui associe une annotation de vj à
Figure imgf000022_0001
sa classe représentée comme un entier, et Cj . l'ensemble des classes acceptables, alors étant donnée une région r, on a
Figure imgf000022_0004
sinon.
[0149] Dans le cas multi-classes où la vue parente permet d'annoter la région avec plusieurs classes parmi un ensemble possible de N classes, on peut représenter la fonction de classe par class ; 'les classes acceptables comme une formule logique
Figure imgf000022_0005
booléen sur les classes : - Dans ce cas on a
Figure imgf000022_0003
Cette variante englobe en fait le cas précédent où
Figure imgf000022_0002
l'on n'a qu'une seule classe annotée à la fois.
[0150] Selon des modes de réalisation lorsque l'annotation de la vue parente ne comporte pas de notion de classe, comme par exemple dans le cas de l'estimation de pose ou une annotation textuelle, on peut définir des « clusters » sur lesquels on peut aussi appliquer des conditions.
[0151] On utilise la notion de clustering lorsque l'annotation d'une vue vj ne fournit pas di- rectement de classe (ou type). C'est par exemple le cas pour une tâche d'estimation de pose où l'annotation correspond à placer les nœuds d'un arbre sur la donnée. On peut alors dans ce cas calculer au préalable une partition de l'espace des annotations (clustering en anglais). Cette méthode divise l'espace A . en Ar groupes (ou “clusters”) et on peut associer toute annotation . au cluster le plus proche, c'est-à-dire que l'on dispose d'une fonction class . : qui permet d'associer une classe à une
Figure imgf000022_0006
annotation.
[0152] Dans certaines variantes, chaque annotation peut être associée à plusieurs clusters et la fonction de classe a la forme générale class ’ A {0,1 }/V- On retombe alors exactement dans le cas du paragraphe précédent pour le cas de l'annotation multi- classes.
[0153] Dans ce qui précède, on a associé les tâches et les vues de manière bijective. Cependant, selon des modes de réalisation, une tâche peut être divisée sur plusieurs vues afin notamment réduire le nombre de classes à annoter dans chaque vue. Cela permet à une personne (ou un module d'annotation) qui annote de se concentrer sur moins de classes, donc d'être plus efficace et de faire moins d'erreurs.
[0154] Cela ne change rien au mode de réalisation général selon lequel, en pratique il est suffisant de garder le lien bijectif entre vue et tâche. C'est seulement au moment d'entraîner un algorithme de machine learning sur un ensemble de dataset annoté qu'il faut pouvoir combiner deux vues sœurs (i.e ayant le même parent) en une unique vue.
[0155] Comme cela a été expliqué, le système des vues permet d'automatiser la mani- pulation des données et annotations, de manière à ce que le flux de données annoté par les différentes vues corresponde à un ensemble de datasets qui partageraient une structure hiérarchique. Dans ce schéma, une fois que des données ont été annotées pour une vue donnée, on peut alors entraîner un modèle de machine learning sur le dataset qui correspond aux données annotées de cette vue.
[0156] Selon des modes de réalisation, cela revient à dire qu'un modèle est entrainé sur les données annotées par une certaine vue. Cependant, il peut être intéressant d'entraîner un modèle sur plusieurs vues.
[0157] Il convient alors d'être capable de fusionner les données annotées issues de plusieurs vues en un unique ensemble de données annotées.
[0158] Les étapes d'un procédé sont maintenant décrites en référence à la [fig.11] et suivantes, en utilisant le formalisme décrit ci-avant. Ce procédé peut être mis en œuvre dans le cas d'une application d'annotation mise en œuvre par ordinateur, avec par exemple une interface comme décrite ci- avant. C'est ainsi un utilisateur qui interagit avec l'application, via l'interface pour annoter les données. Des variantes du procédé peuvent aussi être mises en œuvre dans le cadre d'une annotation automatique, par une IA par exemple.
[0159] Dans ce qui suit, on considère que des données (par exemple des images) sont déjà stockées en mémoire et associées à leur région racine. Cette association est réalisée dès l'ajout d'une donnée à la base de données : une région racine est créé pour chaque donnée ajoutée. Alternativement, on peut prévoir dans ce qui suit des étapes d'ajout ou de suppression de données à un dataset existant, soit par un utilisateur ou soit automa- tiquement. Ces étapes ne sont pas représentées.
[0160] Dans le cas d'une application, l'utilisateur peut par exemple créer un projet d'annotation dans lequel des données à annoter et des annotations vont être stockées selon l'invention. Il s'agit par exemple d'un projet « Plateaux repas » ou « Pac- cordementfibre ».
[0161] On décrit dans la [fig.11] le procédé de création d'une vue. Lors d'une étape 1101, la description d'une vue, correspondant à une tâche du projet, est créée. Il est ensuite déterminé (étape 1102) si cette vue est une vue racine. Si ce n'est pas le cas (N), le processus se poursuit avec la sélection de la vue parente lors de l'étape 1103. L'interface de la [fig.5] peut par exemple être utilisée, par exemple il est déterminé si c'est le bouton 513 ou 515 qui a été activé. Dans ce cas la détermination de la vue parente se fait en déterminant la vue précédemment sélectionnée par l'utilisateur avant de cliquer sur l'un de ces boutons. Si c'est le bouton 508 qui a été activé, il est alors déterminé (Y) que la vue crée est une vue racine.
[0162] Une fois la vue parente sélectionnée, une condition sur cette vue parente est définie (étape 1104) pour permettre de filtrer les données à proposer à l'annotation pour la vue créée à l'étape 1101. La forme exacte de cette condition dépend du type de tâche de la vue parente. Par exemple, si la vue parente est une vue de classification ou de détection où une seule classe peut être annotée, la condition peut prendre la forme d'une liste dé- roulante dans laquelle l'utilisateur sélectionne les différentes classes parentes d'intérêt, ce qui permet de définir l'ensemble C . des classes acceptables défini ci-dessus. Si le type de tâche parente est multi-classes et permet d'annoter plusieurs classes sur la même région, la condition pourra être définie par une formule booléenne dont les clauses porteront sur la présence de certaines classes parente. Ensuite, le type d'annotations pour cette vue est créé (étape 1105), c'est-à-dire le type de tâche associée (classification, OCR, pose, détection ou autre). En fonction du type de tâche, la configuration de l'annotation est ensuite définie (étape 1106). Par exemple pour des annotations basées sur des classes, on définit les classes d'intérêt : « Ecran » ou
« Armoire » dans l'exemple du raccordement de fibre. Cette étape est optionnelle car les classes peuvent être modifiées après la sauvegarde de la vue en mémoire : l'utilisateur peut par exemple utiliser les boutons de la zone d'action 601 de l'interface 600 de la [fig.6] par exemple.
[0163] Si la vue crée est une vue racine, le processus passe de l'étape 1102 (Y) à l'étape 1105 directement.
[0164] Une fois ce processus terminé, la description de la vue est stockée en mémoire (étape 1107).
[0165] Ensuite, en référence à la figure 12, on décrit le processus d'annotation. Il débute par la sélection d'une vue vj lors de l'étape 1201. Il est ensuite déterminé lors de l'étape 1202 si la vue sélectionnée est une vue racine ou non.
[0166] S'il s'agit d'une vue racine (Y), on initialise une boucle (étape 1203) lors de laquelle on va déterminer (étape 1204) toutes les régions non encore annotées selon la vue courante. On itère donc sur les régions racines des données en mémoire : si la région n'est pas annotée par la vue vj, celle-ci est sélectionnée (étape 1205). Sinon (N) la région est ignorée. L'itération se fait typiquement via une requête à une base de données mais peut être implémentée par un compteur i qui parcourt toutes les régions racines. Lors de l'étape 1206, si i n'a pas encore terminé d'itérer sur les régions racine (N), on incrémente la boucle (étape 1207) ou alors (Y), si toutes les régions ont été testées, on passe à une étape de mémorisation 1208 de toutes les régions filtrées dans l'étape 1205. Il ne s'agit pas d'un stockage d'un nouveau dataset ou la création d'un sous-dataset mais de la mémorisation de l'ensemble des régions à annoter selon la vue courante, typiquement selon un curseur renvoyé en réponse de la requête à la base de données.
[0167] Cette étape est un préalable à un affichage des données pour l'utilisateur, par exemple pour préparer l'affichage des données à annoter de la zone 705 de l'interface 700 de la [fig.7],
[0168] De retour à l'étape 1202, si la vue sélectionnée n'est pas une vue racine (N), alors une boucle est initialisée (étape 1209), lors de laquelle, on détermine (étape 1210) toutes les régions des données annotées par la vue parente.
[0169] Pour chaque région annotée par la vue parente (Y), on détermine si elle est annotée par la vue courante lors de l'étape 1211. Si la région n'est pas annotée par la vue courante (Y), alors on détermine (étape 1212) si la condition de filtrage de la vue parente est remplie pour la région courante. Si la condition est respectée (Y), alors on sélectionne la région (étape 1215) pour la présenter à l'annotation.
[0170] Le processus continue ensuite jusqu'à ce que toutes les régions aient été considérées. Ceci est déterminé lors de l'étape 1216. S'il reste des régions à considérer (N), on in- crémente la boucle lors de l'étape 1217 et on reprend à l'étape 1210. Autrement (Y), le processus se termine avec l'étape 1208 déjà décrite en mémorisant les régions filtrées lors de l'étape 1215.
[0171] Lors des tests des étapes 1210, 1211 et 1212, si le résultat est négatif (N), le processus continue avec l'étape 1216 comme illustré par la [fig.12] .
[0172] Les données correspondant aux régions à annoter mémorisées à l'étape 1208 sont soit affichées pour annotation par un utilisateur, par exemple via l'interface 705, soit fournies à un module d'annotation automatique.
[0173] Cette annotation (manuelle ou automatique) est décrite en référence à la [fig.13].
[0174] Pour chaque région r mémorisée à l'étape 1208, on présente à l'utilisateur (humain ou algorithme) la donnée d à laquelle r est rattachée, recadrée par 1 . Formellement, on présente à l'étape 1300 la donnée crop d, r) à l'utilisateur pour annotation selon la vue vj sélectionnée en 1201. On reçoit à l'étape 1301 une annotation pour cette donnée. Il est ensuite déterminé à l'étape 1302 si le type de type de tâche liée à vj est créatrice de régions. Si ce n'est pas le cas (Y), alors on passe à l'étape 1303 de mémo- risation de l'annotation. Comme déjà indiquée, cette mémorisation se fait en lien, non pas avec les données mais avec la vue courante et la région à laquelle appartient la donnée.
[0175] Si par contre l'annotation crée une ou des régions (N), notées par exemple s'il s'agit d'une vue liée à une tâche de détection, on passe à une étape de mémorisation 1304 d' un lien de parenté entre les régions crées et les régions dont elles sont issues. On passe ensuite à une étape 1305 de mémorisation de l'annotation en lien avec la région crée et la vue courante et ce, pour chacune des régions crées. Par exemple, dans le cadre de la détection, on associe une classe annotée sur une boîte englobante à la région correspondante.
[0176] A l'issue du processus, on peut disposer d'une base de données selon la [fig.9] qui stocke annotations en lien avec les vues, les régions et les conditions. La base de données contient aussi les données initiales.
[0177] Comme déjà expliqué, de manière avantageuse, il n'a pas été procédé à des créations de sous-datasets. Ainsi, on peut corriger, mettre à jour les annotations à un niveau et propager facilement les changements dans les vues enfants, ce qui contribue à fiabiliser le processus d'annotation.
[0178] Seule la visualisation peut être réalisée de manière temporaire pour permettre à l'utilisateur de visualiser les données des sous datasets et les annoter ou pour permettre à un processus automatique de les prendre en entrées et les annoter. Ce processus étant réalisé donnée par donnée, il reste léger et ne présente pas de complexité d'exécution.
[0179] La génération des datasets se fait alors au moment d'entraîner l'IA. Soit elle se fait en une seule fois, ou alors à la volée au fur et à mesure de l'entraînement.
[0180] La [fig.14] illustre une utilisation d'annotations produites selon des modes de réa- lisation.
[0181] Le processus est initialisé par l'étape 1401 lors de laquelle on accède aux an- notations, par exemple à une base de données selon la figure 9. On initialise ensuite une boucle (étape 1402) lors de laquelle on sélectionne les différentes vues vj (étape 1403) et on les applique aux données initiales lors de l'étape 1404.
[0182] Le résultat du filtrage est stocké en mémoire lors de l'étape 1405, avec les an- notations associées à la vue vj. Ainsi, ici on fait le lien entre les données et les an- notations. On commence ainsi à construire le dataset qui va être utilisé par l'IA.
[0183] On vérifie ensuite (étape 1406) si toutes les vues ont été considérées. S'il reste des vues (N), on incrémente la boucle (étape 1407) et on retourne à l'étape 1403.
[0184] Si toutes les vues ont été utilisées (Y), alors on passe à l'étape 1408 de fourniture du dataset à l'IA qui peut ensuite être entraînée lors de l'étape 1409 selon l'application.
[0185] En outre, on peut aussi prévoir que les données sont aussi liées à des applications particulières. Dans ce cas, les vues seront aussi appliquées à un sous-ensemble de données lié à l'application considérée.
[0186] La [fig.15] est un schéma fonctionnel d'un système 1500 pour la mise en œuvre d'une ou plusieurs modes de réalisation de l'invention. Les procédés selon des modes de réa- lisation sont mis en œuvre par ordinateur. [0187] Le système 1500 comprend un bus de communication auquel sont connectés :
- une unité de traitement 1501, telle qu'un microprocesseur, dénommée CPU ;
- une unité de mémoire vive 1502, dénommée RAM, pour le stockage de code exécutable d'un procédé selon un mode de réalisation de l'invention ainsi que des registres adaptés pour enregistrer les variables et paramètres nécessaires à la mise en œuvre d'un procédé selon des modes de réalisation, dont la capacité mémoire peut être étendue par une RAM optionnelle connectée à un port d'extension par exemple ;
- une unité de mémoire 1503, appelée ROM, pour le stockage de programmes infor- matiques destinés à mettre en œuvre les modes de réalisation de l'invention ;
- une unité d'interface réseau 1504 connectée à un réseau de communication sur lequel les données numériques à traiter sont transmises ou reçues. L'interface réseau 1504 peut être une interface réseau unique, ou composée d'un ensemble de différentes interfaces réseau (par exemple des interfaces câblées et sans fil, ou différents types d'interfaces câblées ou sans fil). Les données sont écrites sur l'interface réseau pour la transmission ou sont lues à partir de l'interface réseau pour la réception sous le contrôle de l'application logicielle s'exécutant dans le CPU 1501 ;
- une unité d'interface utilisateur graphique 1505 permettant de recevoir des entrées d'un utilisateur ou d'afficher des informations à un utilisateur ;
- un disque dur 1506 noté HD
- un module d'entrées/sorties E/S 1507 pour recevoir/envoyer des données depuis/ vers des systèmes externes tels qu'une source vidéo ou un écran.
[0188] Le code exécutable peut être stocké soit en mémoire morte 1503, soit sur le disque dur 1506, soit sur un support numérique amovible comme par exemple un disque. Selon une variante, le code exécutable des programmes peut être reçu au moyen d'un réseau de communication, via l'interface réseau 1504, afin d'être stocké dans l'un des moyens de stockage du système de communication 1500, comme le disque dur 1506, avant d'être exécuté.
[0189] L'unité centrale de traitement 1501 est adaptée pour contrôler et diriger l'exécution des instructions ou des parties de code logiciel du ou des programmes selon les in- carnations de l'invention, ces instructions étant stockées dans l'un des moyens de stockage susmentionnés. Après la mise sous tension, l'unité de traitement 1501 est capable d'exécuter les instructions de la mémoire vive principale 1502 relatives à une application logicielle après que ces instructions ont été chargées à partir du programme ROM 1503 ou du disque dur (HD) 1506 par exemple. Une telle application logicielle, lorsqu'elle est exécutée par l'unité centrale 1501, entraîne l'exécution des étapes d'une méthode selon des incarnations.
[0190] La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes, modes de réalisation et com- binaisons de caractéristiques peuvent être déduits et mis en œuvre par la personne du métier à la lecture de la présente description et des figures annexées.
[0191] Pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications ou adaptations.
[0192] Dans les revendications, le terme “comporter” n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Les différentes caracté- ristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention.

Claims

Revendications
[Revendication 1] Procédé d'annotation de données d'apprentissage pour une intelligence artificielle comprenant les étapes suivantes :
- stocker, dans une base de données, un ensemble de données à annoter (901),
- stocker, dans ladite base de données, au moins une première des- cription d'une première facette de sélection de données dans ledit ensemble de données, ladite première description étant associée à une première tâche à faire exécuter par ladite intelligence artificielle (902),
- sélectionner ladite première facette dans ladite base de données (1201),
- appliquer ladite première facette à des données dudit ensemble de données pour obtenir des premières données filtrées (1300),
- recevoir au moins une première annotation desdites premières données filtrées (1301), et
- stocker ladite première annotation dans la base de données en as- sociation avec ladite première facette (1303, 1304, 1305).
[Revendication 2] Procédé selon la revendication 1, dans lequel ladite base de données comporte une pluralité de descriptions d'une pluralité de facettes de sélection de données dans ledit ensemble de données et dans lequel
- ladite première description comporte un lien hiérarchique vers une deuxième description d'une deuxième facette de données dans la base de données (1103),
- ladite première facette est appliquée à des deuxièmes données filtrées obtenues par application de ladite deuxième facette à des données dudit ensemble de données (1215).
[Revendication 3] Procédé selon la revendication précédente, dans lequel
- ladite deuxième facette porte sur une pluralité de régions dans ledit ensemble de données, et
- la première facette est appliquée sur chaque région sur laquelle porte la deuxième facette.
[Revendication 4] Procédé selon la revendication précédente, dans lequel
- des annotations sont associées à certaines desdites régions sur lesquelles porte ladite deuxième facette ainsi qu'à ladite deuxième facette, et
- la première facette est appliquée sur chaque région portant une an- notation associée à la deuxième facette.
[Revendication 5] Procédé selon l'une des revendications 2 à 4, dans lequel, la description de la première facette comporte une condition de filtrage appliquée aux annotations associées auxdites régions ainsi qu'à ladite deuxième facette et dans lequel la première facette n'est appliquée que pour les régions pour lesquelles ladite condition de filtrage est vérifiée (1212).
[Revendication 6] Procédé selon la revendication 5, dans lequel ladite condition de filtrage est associée aux régions annotées par ladite deuxième facette et dans lequel la première facette n'est appliquée que sur les données issues d'un recadrage par ces régions (1300) et pour lesquelles la condition est vérifiée.
[Revendication 7] Procédé selon la revendication 6, dans lequel, ladite annotation génère la définition d'une région dans ledit ensemble de données, ladite région est stockée en base de donnée en relation avec la région ayant servi au recadrage de la donnée annotée (1304) et dans lequel ladite annotation est stockée dans ladite base de donnée en relation avec ladite première facette et ladite région (1305).
[Revendication 8] Procédé selon la revendication 6, dans lequel, ladite annotation ne crée pas de nouvelle région et dans lequel ladite annotation est stockée dans ladite base de données en relation avec ladite première facette ainsi que la région ayant servi au recadrage de la donnée annotée (1303).
[Revendication 9] Procédé selon l'une quelconque des revendications précédentes, comportant en outre une étape d'affichage desdites premières données filtrées pour un utilisateur, ladite annotation étant reçue de la part dudit utilisateur.
[Revendication 10] Procédé selon l'une des revendications 1 à 8, dans lequel lesdites premières données filtrées sont fournies en entrée à un module d'intelligence artificielle mettant en œuvre ladite tâche, ladite annotation étant reçue de la part dudit module.
[Revendication 11] Procédé d'apprentissage machine, pour l'exécution d'une tâche par une intelligence artificielle, comportant les étapes suivantes :
- accéder (1401) à une base de données comportant un ensemble de données et au moins une définition d'au moins une facette de sélection de données dans ledit ensemble de données, ladite une définition comportant en outre au moins une annotation associée à ladite facette,
- appliquer (1404) ladite facette de sélection de données audit ensemble de données pour obtenir des premières données filtrées,
- stocker (1405) lesdites premières données filtrées dans une mémoire de données d'apprentissage annotées,
- associer (1405) lesdites premières données filtrées aux annotations - exécuter (1408, 1409) ladite tâche par ladite intelligence artificielle.
[Revendication 12] Procédé selon la revendication précédente, dans lequel, ladite annotation est générée selon un procédé selon l'une des revendications 1 à 10.
[Revendication 13] Dispositif (1500) comprenant une unité de traitement (1501) configurée pour la mise en œuvre d'étapes selon un procédé selon l'une quelconque des revendications précédentes.
PCT/IB2021/059800 2020-10-26 2021-10-24 Procede d'annotation de donnees d'entrainement WO2022090883A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US18/033,619 US20230394803A1 (en) 2020-10-26 2021-10-24 Method for annotating training data
EP21795015.3A EP4232970A1 (fr) 2020-10-26 2021-10-24 Procede d'annotation de donnees d'entrainement

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2010970A FR3115624A1 (fr) 2020-10-26 2020-10-26 Procede d’annotation de donnees d’entrainement
FRFR2010970 2020-10-26

Publications (1)

Publication Number Publication Date
WO2022090883A1 true WO2022090883A1 (fr) 2022-05-05

Family

ID=74553950

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2021/059800 WO2022090883A1 (fr) 2020-10-26 2021-10-24 Procede d'annotation de donnees d'entrainement

Country Status (4)

Country Link
US (1) US20230394803A1 (fr)
EP (1) EP4232970A1 (fr)
FR (1) FR3115624A1 (fr)
WO (1) WO2022090883A1 (fr)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MAIRE MICHAEL ET AL: "Hierarchical Scene Annotation", 2013, pages 84.1 - 84.11, XP055822277, ISBN: 978-1-901725-49-0, Retrieved from the Internet <URL:https://authors.library.caltech.edu/94260/1/paper0084.pdf> [retrieved on 20210713], DOI: 10.5244/C.27.84 *
XAVIER GIRO-I-NIETO ET AL: "GAT: a Graphical Annotation Tool for semantic regions", MULTIMEDIA TOOLS AND APPLICATIONS, KLUWER ACADEMIC PUBLISHERS, BO, vol. 46, no. 2-3, 27 October 2009 (2009-10-27), pages 155 - 174, XP019773171, ISSN: 1573-7721 *

Also Published As

Publication number Publication date
EP4232970A1 (fr) 2023-08-30
US20230394803A1 (en) 2023-12-07
FR3115624A1 (fr) 2022-04-29

Similar Documents

Publication Publication Date Title
CN104246656B (zh) 建议的视频编辑的自动检测
EP3786783A1 (fr) Systeme d&#39;aide a la conception d&#39;application d&#39;intelligence artificielle, executable sur des plates-formes informatiques distribuees
FR2974433A1 (fr) Evaluation de la qualite d&#39;image
CN106796593A (zh) 基于社交数据和用户行为优先化媒体
FR2955681A1 (fr) Systeme pour navigation et exploration d&#39;images de creation
EP4100902A1 (fr) Traitement amélioré pour des flux de travail de communication à l&#39;aide de techniques d&#39;apprentissage machine
FR3029662A1 (fr) Systeme de simulation, dispositifs, methodes et programmes correspondants.
US11397759B1 (en) Automated memory creation and retrieval from moment content items
EP2593909A1 (fr) Processeur d&#39;analyse situationnelle
FR3100355A1 (fr) Système d’aide à la conception d’application d’Intelligence Artificielle, exécutable sur des plates-formes informatiques distribuées
US20180124271A1 (en) Sensory and cognitive milieu in photographs and videos
US20190034455A1 (en) Dynamic Glyph-Based Search
FR3067496A1 (fr) Procede d&#39;apprentissage de descripteurs pour la detection et la localisation d&#39;objets dans une video
US20220083881A1 (en) Automated analysis generation for machine learning system
FR3026874B1 (fr) Procede et dispositif d&#39;aide a la decision
US11601693B2 (en) Automatic adaptation of digital content
WO2022090883A1 (fr) Procede d&#39;annotation de donnees d&#39;entrainement
EP1262884A1 (fr) Génération d&#39;une description dans un langage de balisage d&#39;une structure d&#39;un contenu multimédia
US20220335026A1 (en) Automated memory creation and retrieval from moment content items
US20220366191A1 (en) Automatic generation of events using a machine-learning model
WO2015062991A1 (fr) Procédé d&#39;analyse sémantique d&#39;un flux vidéo en cours d&#39;acquisition, terminal, produit programme d&#39;ordinateur et medium correspondant
US20220335538A1 (en) Automated memory creation and retrieval from moment content items
US11107285B2 (en) Augmented reality-based image editing
US11822591B2 (en) Query-based granularity selection for partitioning recordings
Scheidegger Provenance of Exploratory Tasks in Scientific Visualization: Management and Applications.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21795015

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021795015

Country of ref document: EP

Effective date: 20230526