projet de fin d'année - glossip · la vidéo est la touche multimédia la plus subtile et la...

Projet de Fin d'Année

2ème

année

Encadré par:

M. Rachid OULAD HAJ THAMI M. Youssef HADI

Réalisé par:

Mossaab BAGDOURI Saad SARHANI

Année Universitaire : 2005 - 2006

Université Mohammed VI Ecole Nationale Supérieure

d’Informatique et d’Analyse des Systèmes

Développement d'une application de segmentation de la vidéo en se basant sur les histogrammes de couleurs

ENSIAS, 2ème année, PFA A. U. 2005 - 2006

àÝƒ˜@ @

ى مع صعوبة معالجة مقطع الفيديو آوحدة متصلة، يصبح االنتقال إلى المجال المنفصل ال غن .حيث يتحول األمر إلى معالجة أسهل للصور المتتابعة. عنه

مساحات متتالية لكل واحدة وفي هذا الصدد، تمكن عملية التجزئة من تقسيم داللي للمقطع إلى .وبذلك يمكن القيام بتخزين تمثيلي لهذه المساحات في قاعدة بيانات. معنى مستقل بذاته

ى دة عل ان ويهدف هذا المشروع إلى الجمع بين تقنية للتجزيء معتم وان مع مبي ات األل إمكانيJMF لـJava.

Résumé Le traitement de la vidéo en tant qu'entité continue est délicat. Le passage au

domaine discret s'avère indispensable pour éditer une vidéo étant donné que les images

sont plus faciles à manipuler.

Dans ce sens, la segmentation fournit une décomposition sémantique d'une vidéo.

Les plans vidéo qu'elle génère sont des classes indépendantes sémantiquement les unes

des autres. Ceci étant, on a ainsi la possibilité d'effectuer un stockage représentatif de ces

images dans une base de données.

Ce projet intervient donc pour combiner une technique de segmentation basée sur

les histogrammes de couleur avec la richesse de l'API JMF de Java.

Abstract The processing of a video is a tough task. Therefore, it is necessary to pass from the

continuous aspect of a video to the discreet one, as the treatment of a frame is much

easier.

To cut up a video provides a well-based decomposition. In fact, the captured shots

are semantically independent. This helps to store typical data in the database.

Hence comes the interest of this project, as it combines both cut detection

techniques using color histogram and strength of Java’s JMF Library.



RRReeemmmeeerrrccciiieeemmmeeennntttsss………

Il était agréable de nous acquitter d’une dette de reconnaissance envers

tous ceux, dont la contribution au cours de ce projet, a favorisé son aboutissement.

Ainsi, nous tenons vivement à remercier notre encadrant Mr Youssef

HADI qui n’a ménagé aucun effort pour nous aider et nous orienter le long de

notre projet. Nous remercions aussi notre professeur Mr Rachid OULAD HAJ

THAMI pour son encadrement précieux et pour le soutien qu’il nous a donné.

Que le corps professoral et administratif de l’ENSIAS trouve ici nos vifs

remerciements.

Nous remercions enfin toute personne qui a contribuée de près ou de loin à

l’élaboration de ce rapport.



Table des matières

Liste des figures ................................................................................................ 5

Introduction ...................................................................................................... 6

Chapitre 1 : Segmentation de la vidéo par les histogrammes de couleurs ... 8 1.1. Introduction ............................................................................................................ 8

1.2. Travaux antérieurs ................................................................................................ 9

1.3. Méthode proposée .................................................................................................. 9 1.3.1. La transformation réversible de couleur .................................................... 11 1.3.2. L’histogramme de couleur ........................................................................... 12

Chapitre 2 : Analyse et conception .............................................................. 14 2.1. UML ...................................................................................................................... 14

2.2. Analyse .................................................................................................................. 16

2.3. Conception ............................................................................................................ 17 2.3.1 Les cas d’utilisation........................................................................................ 17 2.3.2 Les diagrammes de séquence ........................................................................ 17 2.3.3. Le diagramme de classes .............................................................................. 21

Chapitre 3 : Outils de développement .......................................................... 23 3.1. Java........................................................................................................................ 23

3.1.1 Java Virtual Machine .................................................................................... 25 3.1.2 Java est interprété .......................................................................................... 25 3.1.3 Java est robuste .............................................................................................. 25 3.1.4 Types d’applications Java ............................................................................. 26

3.2. Java Media Framework : JMF ........................................................................... 26 3.2.1. Architecture JMF .......................................................................................... 26

3.3. XML ...................................................................................................................... 30 3.3.1. Caractéristiques ............................................................................................ 30 3.3.2. JDOM ............................................................................................................. 31

Chapitre 4 : Réalisation de l'application ...................................................... 33

Conclusions et perspectives .......................................................................... 38

Références ....................................................................................................... 39



Liste des figures

Figure 1 - Diagramme des cas d’utilisation ...................................................................................... 17 Figure 2 - Diagramme de séquence du cas chargement de la vidéo ......................................... 18 Figure 3 - Diagramme de sequence du cas Play Vidéo ................................................................. 19 Figure 4 - Diagramme de sequence du cas Segmentation Vidéo ............................................... 20 Figure 5 - Diagramme de classes ........................................................................................................ 21 Figure 6 - Etapes de compilation ......................................................................................................... 24 Figure 7 - Player ....................................................................................................................................... 27 Figure 8 - Différents états d’un Player ............................................................................................... 27 Figure 9 - Processor ............................................................................................................................... 28 Figure 10 - Différents états d’un Processor ...................................................................................... 29 Figure 11 - Menu principal ..................................................................................................................... 33 Figure 12 - New Project .......................................................................................................................... 34 Figure 13 - Play Video ............................................................................................................................. 35 Figure 14 - Load Project ......................................................................................................................... 36 Figure 15 - Fichier XML .......................................................................................................................... 37



Introduction

La vidéo est la touche multimédia la plus subtile et la plus prometteuse. L'essor

qu'ont connu les méthodes de traitement des vidéos est énorme. Mais c'est quoi d'abord

une vidéo? Une vidéo regroupe l'ensemble des techniques permettant la visualisation ou

l'enregistrement d'images animées accompagnées du son sur un support électronique.

Le traitement d'une vidéo requiert des connaissances solides sur les fichiers vidéo.

En effet, chaque type dispose de ces propres caractéristiques, et est donc plus sensible ou

moins au différents traitements, notamment la segmentation.

Il existe plusieurs formats des documents vidéo et se diffèrent par la technique de

compression utilisée :

• AVI (Audio Video Interleave : Video For Windows)

L'Audio Video Interleave (audio vidéo entrelacée) (dont l'acronyme est AVI), est

un format de fichier conçu pour stocker des données audio et vidéo. AVI utilise

un même paquet standard « fichier conteneur » afin d'être lu simultanément. Il a

été présenté par Microsoft en novembre 1992, en tant qu'élément de la vidéo pour

la technologie de Windows. Dans un fichier AVI, chaque composante audio ou

vidéo peut être compressé par n'importe quel codec. Le format DivX est souvent

utilisé comme codec vidéo, et le format mp3 comme codec audio, mais d'autres

codecs peuvent également être utilisés, par exemple XviD ou MPEG pour la

vidéo, et mp2, WAV etc. pour l'audio.

Le format AVI permet de réunir en un seul fichier une piste vidéo et jusqu'à 99

pistes audio, ce qui permet de bénéficier, par exemple, de plusieurs langues pour

un même film



• MPEG (Moving Pictures Expert Group)

MPEG, acronyme de Moving Picture Experts Group est le groupe de travail SC

29/WG 11 du comité technique mixte JTC 1 de l'ISO et de la CEI pour les

technologies de l'information chargé du développement de normes internationales

pour la compression, la décompression, le traitement et le codage de la vidéo, de

l'audio et de leur combinaison, de façon à satisfaire un large panel d'applications.

Les formats produits par MPEG sont ouverts, mais non libres : leur utilisation est

soumise au paiement de royalties.

Le travail que nous avons réalisé consiste à développer une application de

segmentation de la vidéo qui se base sur les histogrammes de couleurs. Le

développement a été réalisé en Java sur la plateforme NetBeans 5.0 en utilisant le

framework JMF (Java Media Framework) comme bibliothèque du traitement de la vidéo.

Afin de bien structurer la segmentation effectuée, une base de données native XML a été

adoptée.

Le présent document est structuré comme suit: le premier chapitre présente les

différentes approches de segmentation qui existent actuellement, puis le détail de la

méthode qui a été adoptée. Le deuxième chapitre fournit une analyse et une conception

globales indispensables pour l'implémentation de l'application. Le troisième chapitre est

un survol des outils de développement qui ont été choisis. Le quatrième chapitre illustre

les interfaces de l'application par l'intermédiaire de prises d'écrans. Finalement, une

conclusion et quelques perspectives ont été proposées.



Chapitre 1 :

Segmentation de la vidéo par les

histogrammes de couleurs

Dans ce chapitre, nous présentons la méthode qui sera utilisée pour réaliser la

segmentation d’une vidéo. Nous parlerons aussi des autres méthodes qui existent.

1.1. Introduction

Les données multimédia prennent une part de plus en plus importante dans les

applications actuelles. La plupart de ces applications nécessitent des outils pour

segmenter des séquences d’images dans le domaine temporel. Cette segmentation est

souvent effectuée par une détection des cuts (transitions brusques) ou d’autres effets plus

complexes (fondu, volet...). La segmentation est une étape cruciale dans des applications

telles que la gestion de bases de données multimédia ou la création automatique de

résumés de séquences télévisées ou de films. Elle peut être aussi utilisée comme

prétraitement pour le suivi d’objet en temps réel dans des scènes dynamiques (acquises

avec une caméra en mouvement).

Nous définissons le problème de segmentation vidéo comme la détection

automatique des frontières qui séparent les plans. Une vidéo peut être divisée en plus

petites composantes appelées plans qui sont des suites d’images qui proviennent d’une

seule opération d’enregistrement d’une unique caméra et qui représentent chacun une



action continue dans l’espace et le temps. Au cours du montage, les plans peuvent être

combinés de plusieurs façons pour produire la vidéo finale. Les frontières diffèrent en

fonction de la technique utilisée pour combiner deux plans. Le type le plus simple est la

coupure franche et résulte d’une simple juxtaposition de deux plans. D’autres types de

frontières telles les fondus et les volets résultent de l’addition d’images entre les plans

pour produire des effets de transitions plus graduels. Un fondu en ouverture fait

progressivement apparaître un plan à partir d’une image noire. A l’inverse, un fondu en

fermeture fait progressivement disparaître un plan vers une image constante. Un fondu

enchaîné est une combinaison d’un fondu en ouverture et un fondu en fermeture. Un

volet est une transition graduelle dans laquelle une image semble en pousser une autre en

dehors de l’écran. Dans cet article, nous sommes concernés par la détection des

transitions brusque de plans vidéo (coupure franche).

Nous rappellerons tout d’abord quelques méthodes classiques de détection des

changements de plan. La méthode proposée sera ensuite présentée.

1.2. Travaux antérieurs

Plusieurs méthodes ont été proposées pour la détection des coupes vidéo. La

plupart d’entres-elles définissent une mesure de différence, locale ou globale, entre les

trames consécutives en vue d’identifier les frontières de plans. Quand une image et

l'image suivante sont suffisamment différentes, une transition brusque (coupe) peut être

déterminée. Les méthodes présentes dans la littérature peuvent être principalement

regroupées en trois catégories utilisant respectivement les différences pixel à pixel, la

comparaison d’histogrammes, et l’estimation de mouvement. Il est important de noter

que les méthodes peuvent traiter des séquences vidéo non compressées ou compressées

[1].

Les méthodes basées sur les différences pixel à pixel détectent un changement de

plan en calculant une différence entre les pixels de l’image à l’instant t et ceux de l’image

à l’instant t+1. Si le nombre de pixels différents est supérieur à un seuil, alors on

considère que l’on est en présence d’un cut ou d’un autre effet. Dans [2], la comparaison

pixel à pixel a été présentée pour évaluer les différences en valeurs d'intensité ou de



couleur des pixels correspondants dans deux images successives. Le défaut principal de

ces méthodes est leur manque de robustesse au bruit et aux forts mouvements pouvant

être présents dans la scène. Les méthodes à base d’histogramme comparent deux images

successives en s’appuyant sur leurs histogrammes respectifs. Une différence des deux

histogrammes est calculée et comparée à un seuil. Comme dans le cas des méthodes

basées sur les différences pixel à pixel, un changement de plan est détecté si la différence

obtenue est supérieure au seuil. Plusieurs recherches ont été proposé pour prouver leur

performance, comme l’égalization d'histogramme [3], intersection d'histogramme [4],

histogramme sur le groupe d'images [5], et les teste normalisés [6]. Une autre question

intéressante est quel espace de couleur utilisé quand nous considérons des techniques

basées sur la couleur comme la comparaison d'histogramme de couleur [7]. Les

histogrammes monochromes et les histogrammes de couleur avec différents espaces de

couleur sont le plus utilisés pour détecter et identifier les transitions dans les plans vidéo.

Dans MPEG-7, les descripteurs de couleur emploient les différents espaces de couleur

[8], comme le monochrome, le RGB, le HSV, et le HMMD. Du fait de l’utilisation

d’histogrammes, il est possible de ne pas détecter un cut si les deux images concernées

ont un histogramme similaire mais un contenu différent. Les méthodes basées sur une

estimation du mouvement utilisent l’information de mouvement comme critère principal

pour la détection des changements de plan [1]. Les mouvements sont estimées pour

chaque pixel d’une image obtenue à l’instant t, et sont comparés avec ceux de l’image

correspondant à l’instant t+1. Les approches basées sur les blocks utilisent des

caractéristiques locales pour augmenter la robustesse aux mouvements des objets et le

mouvement de la caméra. Chaque image est divisé en un certain nombre de blocs et

comparés par la suite avec leurs contreparties dans l'image successive. Typiquement, la

similarité ou la dissimilarité entre deux images peut être mesurée en employant un

rapport de probabilité, comme proposé dans [2], [9]. Une frontière de transition est

identifiée si le nombre de blocs changés est au-dessus du seuil donné. Évidemment, cette

approche fournit une meilleure tolérance au mouvement ralenti ou petit entre les images.

Un nombre trop important de mouvements incohérents entre les deux images successives

implique alors la détection d’un changement de plan. Ces méthodes ne sont souvent pas



capables de traiter des séquences vidéo en temps réel, du fait des ressources nécessaires

pour les estimations de mouvement. Même si les différentes méthodes présentées

précédemment ont leurs propres avantages et inconvénients, elles utilisent toutes des

seuils fixés la plupart du temps de manière empirique. Ces seuils nécessitent des

paramétrages spécifiques au type de séquence vidéo analysée, et ne permettent donc pas

une acquisition de données non contrainte ni une méthode générique, c’est-à-dire

indépendante du domaine des séquences vidéo traitées.

1.3. Méthode proposée

La méthode adoptée dans ce travail est basée sur les histogrammes de couleurs [10].

La détection des changements de plans est ainsi assurée avec une précision satisfaisante.

1.3.1. La transformation réversible de couleur

Un codage typique des images consiste à attribuer à chaque pixel un triplet unique

associé aux composants rouge (Red), vert (Green) et bleue (Blue) – RGB. La

transformation en question associe chaque triplet (R, G, B) à un entier unique F(R, G, B).

La caractéristique principale de cette transformation est qu’elle est bijective, c'est-à-dire

qu’elle permet de retrouver la couleur (R, G, B) à partir de F(R, G, B).

Soit n un entier codé sur 8 bits, et im sa représentation au èmei bit. On définit le

vecteur U(n) par :

U(n) = )1(38

12 −

=∑ i

iim (1)

La fonction réversible de couleur est définit comme suit :

F(R,G,B) = 4U(G) + 2U(R) + U(B) (2)

R, G, B étant codés sur 8 bits. La fonction F est bijective de [ ]255..0 vers [ [242..0

[10].



Cette transformation est basée sur une décomposition binaire des composantes de

couleurs, réalisée grâce au vecteur U. Remarquons que puisque U ne peut prendre en

argument que les valeurs de 0 à 255, les U(n) peuvent être calculées une fois pour toute.

Le temps de calcul sera ainsi plus rapide.

On constate aussi que dans la relation (2), le composant vert est plus pesant que le

rouge et le bleu. Ceci est dû au fait que l’œil humain est plus sensible aux variations de la

couleur verte qu’aux rouge ou au bleu.

1.3.2. L’histogramme de couleur

Afin de générer un histogramme de couleur à partir de la transformation réversible,

on réalise une quantification du F(R,G,B) de chaque pixel en M niveaux [10].

L’histogramme à M niveaux est établi par la relation :

)(kH F = ),)),,((( ,,, kBGRFQ jijijiF −∑δ pour Mk ≤≤0

=− )( jiδ ⎩⎨⎧

≠=

jipourjipour

01

Où FQ ( ) représente la fonction de quantification qui quantifie ),,( ,,, jijiji BGRF en

une valeur entre 0 à 255.

La différence entre deux histogrammes successives est un histogramme définit par :

idH = 21

0 1

1

)()()()(∑

−

= −

−⎟⎟⎠

⎞⎜⎜⎝

⎛+−M

j ii

ii

jHjHjHjH

pour i=1,2,….L-1

Avec L le nombre total d’images dans la séquence vidéo.

Si la différence idH entre l’image courante et la précédente est supérieure à un

seuil optimal T , l’images courante est considérée comme un cut, tandis que la franche

vidéo est générée automatiquement.



Conclusion

Dans ce chapitre, nous avons parcouru les différents types de méthodes qui

permettent la segmentation temporelle. Puis nous avons détaillé les bases mathématiques

de la méthode choisie. La prochaine partie sera consacrée à l’analyse et la conception de

l’application.



Chapitre 2 :

Analyse et conception

Dans ce chapitre, nous présentons l’analyse et la conception de l’application. Elles

ont été faite en utilisant la notation UML.

2.1. UML

UML est un langage graphique de modélisation des données et des traitements.

C’est une formalisation très réussie de la modélisation objet utilisée en génie logiciel. Il

est l’accomplissement de la fusion des précédents langages de modélisation objet Booch,

OMT Et OOSE.

Le formalisme d’UML

Le formalisme UML est composé de 13 types de diagrammes (9 en UML 1.3) [11].

UML n'étant pas une méthode, leur utilisation est laissée à l'appréciation de chacun,

même si le diagramme des cas d'utilisation est généralement considéré comme l'élément

central d'UML. De même, on peut se contenter de modéliser seulement partiellement un

système, par exemple certaines parties critiques.

UML se décompose en plusieurs sous-ensembles



• Les vues : Les vues sont les observables du système. Elles décrivent le

système d'un point de vue donné, qui peut être organisationnel, dynamique,

temporel, architectural, géographique, logique, etc. En combinant toutes ces

vues il est possible de définir (ou retrouver) le système complet.

• Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci

décrivent le contenu des vues, qui sont des notions abstraites. Les

diagrammes peuvent faire partie de plusieurs vues.

• Les modèles d'élément : Les modèles d'élément sont les briques des

diagrammes UML, ces modèles sont utilisés dans plusieurs types de

diagramme. Exemple d'élément : cas d'utilisation, classe, association, etc.

Les principaux diagrammes d’UML sont:

• Les diagrammes de cas d'utilisation : utilisés pour donner une vision

globale du comportement fonctionnel d'un système logiciel. Les deux

composants principaux des diagrammes de cas d'utilisation sont les acteurs

et les cas d'utilisation.

⇒ Les acteurs : ce sont des entités externes qui interagissent avec le

système.

⇒ Les cas d’utilisation : Ils permettent de décrire l'interaction entre

l'acteur et le système

• Les diagrammes de séquences : permettent de décrire les interactions entre

différentes entités et/ou acteurs : par exemple des objets dans un modèle

d'un logiciel, des sous-systèmes dans un modèle d'un système complet.

Le temps est représenté comme s'écoulant du haut vers le bas le long des

"lignes de vie" (lifeline) des entités, alors que les flèches représentent les

messages qui transitent d'une entité vers l'autre.



• Le diagramme de classes : c’est un schéma utilisé en génie logiciel pour

représenter les classes et les interfaces d'un système ainsi que les différentes

relations entre celles-ci. Les relations possibles entre les classes sont :

⇒ héritage : principe de division par généralisation et spécialisation

⇒ association : connexion sémantique entre deux classes

⇒ agrégation : association avec relation de subordination

⇒ composition : agrégation avec cycle de vie dépendant

2.2. Analyse

Le but de notre application est de capturer les plans d’images à partir d’une vidéo.

Pour ce faire, nous avons opté pour la structuration suivante :

• Toutes les vidéos sont collectées dans une base de données.

• Chaque vidéo est identifiée par un répertoire qui porte le même nom que la

vidéo et qui contient le fichier XML généré ainsi que les images capturées.

Les fonctionnalités apportées par l’application sont :

• La gestion de la vidéo à partir des boutons play, pause, stop, forward…etc

• La décomposition de la vidéo en plans.

• La consultation d’une base de données XML contenant les informations sur

les plans détectés.

• La visualisation de l’image-clé de chaque plan.

• L'accès à une image vidéo par son numéro de séquence.



2.3. Conception

2.3.1 Les cas d’utilisation

L’utilisateur de notre application a le choix entre deux options :

• La lecture de la vidéo qu’il a sélectionnée auparavant

• La décomposition de la vidéo en des plans et/ou la visualisation de ceux-ci

Dans tous les cas, le chargement de la vidéo est indispensable avant d’effectuer

l’une ou l’autre de ces choix.

Segmentation vidéo Play vidéo

Utilisateur Chargement vidéo

<<include>> <<include>>

Figure 1 - Diagramme des cas d’utilisation

2.3.2 Les diagrammes de séquence

Le diagramme correspondant au cas chargement de la vidéo est :



Figure 2 - Diagramme de séquence du cas chargement de la vidéo

Les étapes successives de la phase de chargement sont :

• l’utilisateur choisit une vidéo à partir d’une liste

• l’appel de la méthode configure() du processor crée la connexion avec la

vidéo.

• l’appel de la méthode realize() permet au processor de connaître les

ressources dont il a besoin.

• Enfin, l’état prefetched résultant de prefetch indique que la vidéo est prête à

démarrer.

Une fois chargée, la vidéo peut donc être traitée. Dans le diagramme suivant, nous

avons opté par souci de clarté pour substituer les trois étapes de chargement décrite

précédemment - à savoir configure –-> realize –-> prefetch -, par une méthode virtuelle

charger vidéo qui renvoie un message vidéo_prête.



Figure 3 - Diagramme de sequence du cas Play Vidéo

Afin d’effectuer une lecture de la vidéo, les différentes fonctions proposées sont :

• start : lire la vidéo. Renvoie l’état lu.

• Pause : interrompre la lecture. Renvoie l’état lecture interrompue.

• Stop : arrêter la vidéo. Renvoie l’état vidéo arrêtée.



Enfin, le diagramme associé au cas de segmentation est le suivant :

Figure 4 - Diagramme de sequence du cas Segmentation Vidéo

La méthode cut() de l’objet processor est responsable du découpage des plans

vidéo. Quant à stocker_dans_BD(), elle permet de stocker les données concernant le

vidéo et les images capturées.



2.3.3. Le diagramme de classes

imagenumFrameextension

Planid_Plandébut_Planfin_Plan

1..n1..n

Processornom

start()stop()pause()

Vidéoid_vidéonomhauteurlargeurtotalFramesextension

cut()

1..n1..n

1 11 1BD vidéonomtotal_vidéos

1..n1 1..n1

Figure 5 - Diagramme de classes

Classe BD vidéo

Cette classe est la collection des vidéos que l’utilisateur peut traiter. Elle est

représentée par un répertoire nommé VideoDB.

Classe Vidéo

Cette classe fournit toutes les données concernant une vidéo. L’attribut totalFrames

représente le nombre d’images dans la vidéo. Quant au couple (hauteur, largeur), il forme

les dimensions d’une image quelconque de cette vidéo.

Classe Processor

Cette classe est l’intermédiaire essentiel qui permet l’exécution et la segmentation

d’une vidéo. Ses méthodes correspondent aux boutons qui gèrent la lecture de la vidéo

(lire, interrompre et arrêter).



Classe Plan

Afin de bien illustrer le fonctionnement de cette classe, éclaircissons davantage le

processus de segmentation. Les principales étapes sont :

• On calcule l’histogramme de chaque image, puis la distance entre deux

histogrammes de deux images successives. Un histogramme est une

fonction des couleurs de base rouge, vert et bleu.

• Si cette distance est supérieure à un certain seuil, l’image suivante est

tronquée. Le plan des images est alors l’intervalle d’images entre deux

troncatures successives.

Classe Image

Cette classe est associée aux images appartenant à un plan donné. Connaissant les

attributs Plan, début_Plan et fin_Plan, on peut déduire l’appartenance d’une image au

plan ou non grâce à l’attribut numFrame.

Conclusion

Dans ce chapitre, nous avons décrit les fonctionnalités de l’application, notamment

la lecture et la segmentation d’une vidéo. Nous avons ensuite présenté des diagrammes

UML qui montrent les interdépendances entre ces fonctionnalités.

D’autre part, la présence de deux relations d’agrégation dans le diagramme de

classes illustre le caractère arborescent de l’application. Le recours à une base de données

de type XML se voit ainsi justifiée.

La prochaine partie présente de manière détaillée les différents outils utilisés dans

l’application.



Chapitre 3 :

Outils de développement

Dans ce chapitre, nous allons donner les informations fondamentales concernant les

outils que l’on a utilisés, à savoir Java, JMF et XML.

3.1. Java

Java est à la fois un langage de programmation et une plateforme d'exécution [7].

Le langage Java a la particularité principale d'être portable, puisqu'il peut tourner sur

n'importe quelle machine disposant d'un interpréteur Java. Cette portabilité est

fondamentale sur Internet, où un nombre important de machines et systèmes

d'exploitation différents inondent le marché.

Dans un environnement interprété, le code Java n'est conçu pour aucune plate-

forme spécifique mais est un simple fichier texte dont l'extension est par convention

.java. Ce fichier source doit être un fichier texte dans sa plus simple expression (contient

uniquement les caractères ASCII de base).

Lorsque le programme est prêt à être "essayé", il s'agit de le compiler. Toutefois,

contrairement aux langages compilés traditionnels, pour lesquels le compilateur crée un

fichier binaire directement exécutable par un processeur donné, le code source Java est

compilé en un langage intermédiaire (appelé pseudo code ou bytecode) dans un fichier



portant le même nom que le fichier source à l'exception de son extension (.class). Ce

code intermédiaire est conçu pour une machine virtuelle: la Java Virtual Machine. Cela

explique la lenteur habituelle des interpréteurs, qui sont obligés de décoder chaque ligne

de code avant leur exécution. (voir Figure 6).

Figure 6 - Etapes de compilation

Fichier source

Machine Virtuelle Linux

Machine Virtuelle Windows

Machine Virtuelle Unix

Système Linux Système Windows Système Unix

Pseudo code



Et voici un aperçu des autres aspects de Java :

3.1.1 Java Virtual Machine

Java est décrit à travers une machine virtuelle ou Java Virtual Machine. JVM est

l'équivalent d'un ordinateur virtuel résidant entièrement en mémoire. Cette JVM doit être

implantée sur chaque plate-forme. Une JVM fournit un niveau d'abstraction entre le

programme Java compilé et une plate-forme matérielle.

3.1.2 Java est interprété

Java est un langage interprété, bien que son aspect compilé n’est pas à négliger.

En effet, tous les codes de la JVM doivent être interprétés par chacune des plates-formes.

L’interprétation s’opère via un navigateur World Wide Web (www) ou un environnement

run-time spécial.

3.1.3 Java est robuste

Java se veut robuste dans la mesure où le langage, fortement typé, permet moins de

"bidouillages" que le langage C. Des bugs classiques de programmeurs C comme le

dépassement de tailles de tableau sont impossibles en Java.

Pour garantir la robustesse de Java, celui-ci a été débarrassé des pointeurs, notion

qui existe dans les langages classiques tels que C et C++. Il est impossible de référencer

une adresse mémoire, d'incrémenter ou décrémenter un pointeur pour se déplacer dans

des tableaux. De plus, Java vérifie toujours lors de l'utilisation de tableaux que le

programmeur ne cherche pas à utiliser des portions non allouées.

La gestion de la mémoire, sa désallocalion automatique via un Garbage Collecter

(GC) sont les garants d'une meilleure stabilité des applications. Le garbage collector

fonctionne comme un thread, c’est à dire un processus séparé tournant en tâche de fond

avec une basse priorité. Il fait des pans de mémoire lorsque l'utilisation du CPU est faible

ou lorsqu'un besoin de mémoire se fait sentir pour l'application.



3.1.4 Types d’applications Java

Quatre types d'applications sont générés en Java :

• Les applets, des mini applications : tournant dans le cadre d'un navigateur

Web compatible Java.

• Des applications tournant dans leur propre environnement.

• Des applications en mode texte tournant dans une boîte DOS ou un shell

Unix.

• Des librairies, des collections de classes intégrées dans un package.

3.2. Java Media Framework : JMF

Java Media Framework (JMF) est une large et transparente API utilisée pour les

applications multimédias (Son / Vidéo). Cette API est une initiative de SUN qui souhaite

apporter une solution « time-based media processing » (processeur de media basé sur un

timeline) à Java. Les média basé sur le temps sont des données qui changent par rapport

au temps tels que les vidéos, l’audio, les séquences MIDI et d’autres animations [12].

3.2.1. Architecture JMF

Les différents composants qui forment l’architecture de JMF sont :

3.2.1.1. Data Source.

La source de données (DataSource) encapsule le flux du média.

3.2.1.2. Capture Device.

Cet objet représente un périphérique matériel qui peut être utilisé comme source de

données. Cela peut être un microphone, un appareil photo ou une caméra.



3.2.1.3. Player

Figure 7 - Player

L’objet Player utilise un flux audio ou vidéo en entrée, puis le rend (l’affiche sur

l’écran pour une vidéo et le joue sur les enceintes pour le son). Il peut prendre plusieurs

états :

Figure 8 - Différents états d’un Player

• Unrealized : Le « Player » est instancié.

• Realized : dans cet état, le Player sait précisément les ressources dont il a besoin

et a les informations concernant le type de média qu’il va utiliser. Il peut

également fournir un ensemble de composants visuels et contrôle. L’ensemble

des connexions avec les composants systèmes est établi.



• Prefetching : lorsque l’on appelle la méthode prefetch(), le Player se positionne

de l’état Realized vers Prefetching. Cet état déclare que le média est prêt à

présenter le média. Pendant cette période, le Player pré-charge les données de son

média, obtient les ressources exclusives et fait l’ensemble des traitements utiles à

la lecture du média.

• Prefectched : l’état dans lequel le Player a terminé le Prefetching. Le média est

prêt à démarrer.

• Started : le Player entre dans cet état après appel à sa méthode start(). Le média

est alors prêt à présenter les données du média.

3.2.1.4. Processor

Figure 9 - Processor

Un processor est un type particulier de player. On peut avec un processor contrôler

et modifier les données en entrée et/ou en sortie.

En plus des états indiqués pour le Player, le Processor en intègre deux autres :



Figure 10 - Différents états d’un Processor

• Configuring : un Processor entre dans cet état à partir de l’état unrealized

et lorsque la méthode configure() est appelée. Un Processor est également

dans cet état lorsqu’il se connecte à la DataSource, de multiplexe le flux

d’entrée, et accède aux informations liées au format des données d’entrée.

• Configured : un Processor entre dans cet état lorsqu’il est connecté à la

DataSource et lorsque le format est déterminé.

3.2.1.5. DataSink

L’objet DataSink est l’interface de base pour lire un média à partir d’une

DataSource ou envoyer le résultat vers une destination. DataSink peut être utilisé pour

écrire un média dans un fichier.

3.2.1.6. Manager

Le Manager est une classe qui permet de connecter deux objets différents. Il est

utile notamment pour créer un Player à partir d’une DataSource.



3.3. XML

3.3.1. Caractéristiques

Extensible Markup Language (« langage de balisage extensible »), généralement

abrégé XML, est un standard du World Wide Web consortium qui sert de base pour créer

des langages de balisage : c'est un « méta-langage » [13]. En ce sens, XML permet de

définir un vocabulaire et une grammaire associée sur base de règles formalisées. Il est

suffisamment général pour que les langages basés sur XML, appelés aussi dialectes

XML, puissent être utilisés pour décrire toutes sortes de données et de textes.

Contrairement à HTML - qui est aussi basé sur les balises-, XML décrit le contenu

plutôt que la présentation. C’est ainsi que XML permet de séparer le contenu de la

présentation.

Voici les principaux atouts de XML :

• La lisibilité : aucune connaissance ne doit théoriquement être nécessaire

pour comprendre un contenu d'un document XML

• Autodescriptif et extensible.

• Une structure arborescente : permettant de modéliser la majorité des

problèmes informatiques

• Universalité et portabilité : les différents jeux de caractères sont pris en

compte

• Déployable : il peut être facilement distribué par n'importe quels protocoles

à même de transporter du texte, comme http

• Intégrabilité : un document XML est utilisable par toute application

pourvue d'un parser (c'est-à-dire un logiciel permettant d'analyser un code

XML)

• Extensibilité : un document XML doit pouvoir être utilisable dans tous les

domaines d'applications



Le succès de XML s'explique surtout par la définition d'interfaces de

programmation (API) standard pour les processeurs XML. Les API les plus largement

utilisées sont :

• SAX (acronyme de Simple API for XML): Ce type de parseur utilise des

événements pour piloter le traitement d'un fichier XML. Il est utilisé pour les

traitements au fur et à mesure de la réception d'un document XML.

• DOM (acronyme de Document Object Model) : Le principal rôle de DOM est de

fournir une représentation mémoire d'un document XML sous la forme d'un arbre

d'objets et d'en permettre la manipulation (parcours, recherche et mise à jour).

DOM permet également de générer de nouveaux documents XML, en créant un

arbre logique, qu'on transforme ensuite en document XML

Ces API sont les plus utilisées mais d'autres API à utilisations spécifiques existent,

notamment JDOM pour Java.

3.3.2. JDOM

JDOM présente de grandes similitudes avec le DOM en ce sens qu'il représente un

document XML via une structure arborescente [14]. Cependant, il s'en distingue parce

que JDOM est spécifiquement conçu pour JAVA et que du point de vue du développeur

JAVA, il s'avère beaucoup plus pratique à utiliser.

JDOM utilise DOM pour manipuler les éléments d'un Document Object Model

spécifique (créé grâce à un constructeur basé sur SAX). Il permet donc de construire des

documents, de naviguer dans leur structure, s'ajouter, de modifier, ou de supprimer leur

contenu.

3.3.2.1. Création d’un document XML

Pour créer un fichier XML, Il suffit de construire chaque élément puis de les ajouter

les uns aux autres de façon logique et arborescente. Un noeud est une instance de

org.jdom.Element.



3.3.2.2. Sérialisation JDOM

Afin de visualiser la structure créée sur l’écran ou de l'envoyer en sortie vers un

fichier, JDOM utilise la classe XMLOutputter pour envoyer le code XML vers un flux

encapsulant une connection réseau, un fichier ou toute autre structure dans laquelle on

souhaite placer du code XML.

3.3.2.3. Parcourir une arborescence

On utilise pou cela la classe Java.Util.Iterator qui agit comme un curseur qui pointe

sur les différents nœuds de l’arborescence. La sélection d’un élément associé à tel nœud

se fait quant à elle par la méthode getChildren.

3.3.2.4. L’ajout des attributs

Pour ajouter des attributs au fichier XML, on utilise dans un premier temps le

constructeur new Attribute avec comme paramètres le nom de l'attribut et sa valeur. Dans

un deuxième temps, on affecte l'attribut à l'élément correspondant à l'aide de la méthode

setAttribute() prenant comme paramètre l'attribut que l'on désire attacher.

Conclusion

Les détails des outils mentionnés dans ce chapitre ont montré leur adaptation

pertinente aux besoins de notre application. Le prochain chapitre illustre les résultats de

l’application de ces outils à travers les interfaces réalisées.



Chapitre 4 :

Réalisation de l’application

Dans ce chapitre, nous présentons les différents résultats générés durant la phase de

test de notre application.

Au lancement de l’application, l’utilisateur a le choix entre deux menus : New

Project et Load Project. Le premier permet la lecture et la segmentation de la vidéo, alors

que Load Project permet la visualisation des cuts (miniatures des images capturées).

Figure 11 - Menu principal



Le programme charge les vidéos contenues dans la base de données (le dossier

VideoDB). L’utilisateur doit sélectionner le nom de la vidéo qu’il veut manipuler. Deux

boutons lui sont proposés à ce niveau : Load et Cut.

Figure 12 - New Project

Après le chargement des données par le bouton Load, les autres boutons s’activent.

Le bouton Go to permet d’afficher instantanément l’image dont le numéro de séquence

est celui introduit dans la case.



Figure 13 - Play Video

Si l’utilisateur clique sur Cut, le processus de segmentation démarre. Après un laps

de temps passé dans le traitement, l’utilisateur a le droit d’afficher les miniatures des cuts

à partir de Load Project.



Figure 14 - Load Project

Finalement, l’utilisateur trouvera le fichier XML généré dans le répertoire associé à

la vidéo. Les niveaux de son arborescence sont les suivants:

• La base de données VideoDB des vidéos ;

• Puis la vidéo attribuée par la hauteur, la largeur et le nombre d’images ;

• Et enfin les capture associées à la vidéo, c'est-à-dire les images qui

succèdent immédiatement à une troncature.



Figure 15 - Fichier XML

Conclusion

Dans ce chapitre notre avons fait un tour des différentes fenêtres de notre

application, permettant ainsi d’apprécier leur hiérarchie ainsi que leur facilité

d’utilisation.



Conclusions et perspectives

Le travail qui a été réalisé durant ce projet sort du commun. En effet, il s'agissait de

travailler sur un sujet de recherche de haut niveau qui touche au fond le domaine

multimédia, à savoir effectuer la segmentation d'une vidéo. Outils de développement,

concepts mathématiques… tout à été mêlé pour produire un livrable satisfaisant, c'est-à-

dire qui génère les plans d'images de la vidéo et qui les stocke dans une base de données.

Le processus de réalisation n'a pas été dépourvu d'obstacles. Effectivement, l'API

JMF est très peu utilisée – il n'y a même pas de documentation officielle fournie par Sun

Microsystems. D'autre part, il a fallu beaucoup de patience et d'attention quand il

s'agissait par exemple de calculer les histogrammes ou de mesurer les distances entre les

pixel. La manipulation des objets multimédias de JMF a été quant à elle assez délicate.

Si l'application répond aux tâches de segmentation, le temps d'exécution demeure

néanmoins assez élevé. Ceci étant dû à la portabilité du langage Java, nous envisageons

de restreindre l'utilisation de Java aux interfaces et à certaines parties du code. Pour le

reste, on utilisera du code C/C++ qu'on va intégrer au code java grâce à l'API JNI (Java

Native Interface) de Sun.



Références

[1] Sébastien Lefèvre, Jérôme Holler et Nicole Vincent, Segmentation temporelle de séquences d’images en couleurs compresses et non compresses en temps réel, Congrès francophone ORASIS de Vision par Ordinateur, Cahors (France), Juin 2001, pp. 329-338.

[2] H. Zhang, A. Kankanhalli, and S. Smoliar, Automatic Partitioning of Video, Multimedia Systems, Volume 1, Number 1, 1993, pp. 10-28.

[3] P. Aigrain and P. Joly, The Automatic Real-Time Analysis of File Editing and Transition Effects and Its Applications, Computer and Graphics, Volume 18, Number 1, 1994, pp. 93-103.

[4] M. J. Swain and D. H. Ballard, Color Indexing, International Journal of Computer Vision, Volume 7, Number 1, 1991, pp. 11-32.

[5] A. M. Ferman, A. M. Tekalp, and R. Mehrotra, Robust Color Histogram Descriptors for Video Segment Retrieval and Identification, IEEE Transactions on Image Processing, Volume 11, Number 5, 2002, pp. 497-507.

[6] A. Nagasaka and Y. Tanaka, Automatic Video Indexing and Full Video Search for Object Appearances, IFIP Transactions on Visual Database Systems II, E. Knuth and L. M. Wegner (Eds.), Elsevier, 1992, pp. 113-127.

[7] U. Gargi, S. Oswald, D. Kosiba, S. Devadiga, and R. Kasturi, Evaluation of Video Sequence Indexing and Hierarchical Video Indexing, Proceedings of SPIE Conference on Storage and Retrieval in Image and Video Databases, 1995, pp. 1522-1530.

[8] B. S. Manjunath, J. R. Ohm, V. V. Vasudevan, and A. Yamada, Color and Texture Descriptors, IEEE Trans. CSVT, Vol. 11, No. 6, pp. 703- 715, Jun. 2001.

[9] R. Kasturi and R. Jain, Dynamic Vision, Computer Vision: Principles, IEEE Computer Society Press, Washington DC, 1991, pp. 469-480.

[10] Youssef HADI, Fedwa ESSANNOUNI, Rachid OULAD HAJ THAMI, Ahmed SALAM and Driss ABOUTAJDINE, A New Approach for Video Cut Detection Using Color Histogram, ISIVC 2006, Hammat Tunis, 2006.

[11] Pascal ROQUES et Franck VALLE, UML en action : De l'analyse des besoins à la conception en Java, 2ème édition, EYROLLES, 2003.

[12] http://www.labo-sun.com/resource-fr-articles-998-1-java-j2se-jmf-java-media-framework.htm

[13] http://www.w3.org/TR/2006/PER-xml-20060614

[14] http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001

projet de fin d'année - glossip · la vidéo est la touche multimédia la plus subtile et la...

Documents