1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Core Image




Core image est le nouveau framework de traitement d'image de Tiger. Il rejoint Core Audio, le framework de traitement audio existant d'Apple. Les technologies partagent plus qu'une convention de noms. Elle fournissent toutes les deux une architecture de greffon pour traiter leurs types de données respectifs. Ces greffons s'appellent des "unités" (units). Core Audio utilise des unités Audio, et Core Image utilise des Unités Image.

Core image est conceptuellement très simple. Une image d'entrée passe par une série d'Unités Image en chaîne pour fournir l'image de sortie.

Core Image

Core Image

Le pipe-line de l'image utilise des valeurs flottantes sur 32 bits pour chacun des quatre canaux (rouge, vert, bleu et alpha) pour conserver autant de précision que possible, à travers la chaîne des calculs. Tiger est livré avec 60 Unités Image pré-définies qui couvrent les tâches de manipulation d'image les plus courantes : flou, distorsions, ajustement de couleurs, etc...

Le traitement d'image ne peut être plus simple que dans le diagramme ci-dessus. Mais c'est dans l'implantation que Core Image brille véritablement. Deux aspects le rendent bien plus attractif que le diagramme ci-dessus pourrait le laisser penser.

Bien que Core Image soit conceptuellement une chaîne, avec la sortie d'une Unité Image qui constitue l'entrée de l'unité suivante, une implantation naïve de ce concept serait bien trop lente. La performance se dégraderait linéairement à mesure que le nombre d'unités d'images s'accroît, et il y aurait une quantité considérable d'entrées/sorties associée à chaque lecture ou écriture de tous les résultats intermédiaires.

Core Image

Une implantation naïve de Core Image

Ce n'est pas la façon dont Core Image a été implanté dans Tiger. Au lieu de passer en séquence à travers toutes les Unités Image, en fournissant une image intermédiaire à chaque étape, Core Image utilise ce qu'on appelle une "évaluation paresseuse".

Passer une image par une Unité Image n'entraîne en fait aucune modification. La sortie d'une Unité Image est seulement une "recette" sur la façon de produire le résultat désiré. Quand l'image passe à travers toutes les Unités Image, chaque Unité Image rajoute des étapes supplémentaires à la recette.

Le rendu réel de l'image n'est fait que quand c'est absolument nécessaire. Normalement, à la fin de la séquence des Unités Image. A ce moment là, la recette complète est réellement exécutée, et donne l'image résultante finale. Si bien que l'implantation ressemble plutôt à ceci :

Cœurs inutilisés

Core Image dans Tiger

Il y a une seule étape "accomplir le travail", aucun résultat intermédiaire (potentiellement important) à lire et à écrire, et une seule "Unité Image effective" (le gros nuage sur le diagramme) qui est une combinaison de toutes les Unités Image réelles.

Le deuxième aspect malin de l'implantation de Core Image dans Tiger est la façon dont il produit et exécute le code qui crée l' "Unité Image effective". Core Image inclut un compilateur à la volée (JIT) qui convertit la "recette", ignorante de l'implantation, pour toute la chaîne d'Unité Image, en code optimisé, en choisissant le matériel le plus rapide disponible au moment de l'exécution.

Dans de très nombreux cas, cela veut dire Altivec. Sur les Macs à multi-processeurs, le compilateur à la volée de Core Image va même créer du code SMP qui utilise tous les processeurs disponibles. Comme ce code est créé à la volée, et adapté à un ensemble spécifique d'Unités Image qui constitue la recette complète, les possibilités d'optimisation ne sont limitées que par l'intelligence du compilateur à la volée.

Si une carte vidéo moderne est installée, Altivec peut ne pas être "le matériel le plus rapide disponible". A la place, le compilateur à la volée peut cibler un GPU, et produire (pour l'essentiel) un calculateur de pixels pour exécuter la recette via OpenGL. C'est exactement dans les attributions préférées d'un GPU, et le travail est fait rapidement.

A quelle vitesse ? La démo standard de Core Image montre une poignée d'Unités Image appliquées à une image source, chacune s'exécutant immédiatement quand elle est appliquée. Quand la recette est complète, chacune des Unités Image peut être ajustée (augmenter le rayon d'un flou, ou déplacer le centre d'un effet de distorsion), et l'image est mise à jour en temps réel. C'est impressionnant.

Et ce qui l'est plus encore, c'est que rajouter d'autres Unités Image semble n'avoir aucun effet sur la performance. Du moins, initialement. Tant que le compilateur à la volée de Core Image produit du code qui s'exécute confortablement sur le GPU courant, il n'y a pas de différence perceptible de performance entre une chaîne avec deux Unités Image et une chaîne avec huit. Mais dès que la recette demande plus que le nombre de passes de rendu qu'un GPU est capable de faire, disons, 1/30 ème de seconde, la performance commence à chuter de façon perceptible.

Quiconque voit une démo de Core Image ne peut s'empêcher de penser à Photoshop. Core Image semble faire la même chose que fait Photoshop avec ses fitres, mais Core Image le fait en temps réel. La vision d'un "tueur de Photoshop" animé par Core Image saute rapidement à l'esprit.

Malheureusement, cette vision souffre d'une vue très étroite de ce que Photoshop fait réellement. Bien que Adobe Photoshop ait été initialement (et d'une façon compréhensible) identifié par ses caractéristiques de filtrage d'image quand il fut introduit en 1990, celles-ci sont peut-être les caractéristiques les moins intéressantes de l'application aujourd'hui.

Il n'est pas très difficile, pour un soi disant "tueur de Photoshop" de réimplanter chacun des filtres de Photoshop. (Si c'était tout ce qu'il faut faire pour être "tueur de Photoshop", le GIMP -gratuit- serait l'application graphique dominante de nos jours). La partie difficile est d'atteindre le niveau de quinze années de raffinement dans le domaine du dessin et des outils d'édition, dans la compatibilité et la conversion des formats de fichiers, dans l'intégration du flux de travail, et toutes ces choses qui amènent les clients de Photoshop à revenir, version après version.

Ce n'est pas pour dire que la création d'un "tueur de Photoshop" est impossible, ou qu'une telle application ne peut pas utiliser (ou n'utilisera pas) une technologie comme Core Image. Mais Core Image ne sera pas d'une aide décisive pour ce travail. En fait, en tant que technologie propre au Mac, n'importe quel "tueur de Photoshop" serait probablement obligé de contourner entièrement Core Image.

Désillusions de grandeur mises à part, Core Image est vraiment puissant, et je suis sûr qu'il y a plein d'applications non soucieuses de tuer Photoshop, qui bénéficieront de son usage. En fait, Tiger l'utilise réellement pour implanter la technologie qui suit.