Nouveaux DMD

[car_rod]

Et zou, me revoilà, avec des images construites par programme.
Le code répartit chaque pixel sur l'une ou l'autre demi-image en fonction de sa position sur l'échiquier ("case noir ou blanche" comme je l'ai décrit précédemment).

Image d'origine (l'oeil de Leeloo )

Image agrandie pour simuler du "vrai" 1920x1080 (réduit à 192x108 pour l'exemple)

Et puis les demi-images qui seront recomposées optiquement (je vous propose de le faire vous-même via PhotoShop ou autre)


Je dois fignoler le programme pour qu'il soit "utilisable". Mais pas de miracle, il ne fonctionnera qu'en ligne de commande et n'acceptera que des images TGA rgb 24 bits non compressées .

[car_rod]

Maintenant que j'ai un programme, c'est facile





Les deux images intermédiaire ne donnent pas grand chose d'explicite, mais combinées le résultat est spectaculaire .

En conclusion, les nouvelles puces de TI seront capables de restituer une résolution donnée avec deux fois moins de miroirs que requis à priori. Par contre, la "densité" de pixels sera 2 fois supérieure à cette résolution. Ainsi la puce xHD3, avec 1M miroirs affichera 2M de pixels avec une impression de 4M de pixels!
Et le tout avec une simplicité qui m'épate encore dans son principe algorythmique (en supposant que j'ai pas tout faux, mais au vu des simulations, y'a pas de raison )
Une restriction cependant: pour un pattern de type échiquier "pur" ces nouvelles puces restitueront une image uniforme. Ma foi, on n'en tiendra pas rigueur à TI .

[car_rod]

Le défi va situer dans la recomposition optique des deux images. Je pense que ce sera la plus grande difficulté, le moindre décalage donnant une image loupée.

[BrunoL]

Chapeaux bas pour cette demo!!

Le défi va situer dans la recomposition optique des deux images. Je pense que ce sera la plus grande difficulté, le moindre décalage donnant une image loupée.

Tu veux parler de la précision du "grand" mirroir ? (il utilisera la même technique que les "petits"?)
J'espère que ça ne sera pas une source supplémentaire de désagréments pour les gens "sensibles" ...

[krisscore]

Merci Carlos pour ces explications "parlantes" avec images à l'appui !! Sans toi j'aurais mis 2 ans à comprendre...
D'ailleurs avant tes derniers posts j'étais plutôt réfractaire au xHD3, alors que maintenant j'en bave d'avance !!!

[WhyHey]

Merci pour ces simulations car_rod
et comme tu le dis, la composition de ces 2 1/2 images ne va pas sans poser de probleme...

2 remarques qui se rejoignent sur ta simulation windows:
1: apparition de halo, contour autour des formes (déjà que certain disent que le DLP génére du EE en plus du EE du DVD, si on rajoute encore du EE avec cette méthode, ca va finir par faire beaucoup)
2: apparition de dégradés de couleur: comme s'il fallait avoir une palette de couleur avec 2 fois plus de valeur pour mieux différencier les contours

1 demande:
Car-rod: tu veux pas rajouter l'oeil reconstruit dans ton post ?

Tcha

[MLill]

Merci Carlos, je savais bien que tu allais avoir le courage
Dès ta découverte de l'algorithme du damier j'ai su que l'on avait trouvé la clef et que cela marchait.

En conclusion, les nouvelles puces de TI seront capables de restituer une résolution donnée avec deux fois moins de miroirs que requis à priori. Par contre, la "densité" de pixels sera 2 fois supérieure à cette résolution. Ainsi la puce xHD3, avec 1M miroirs affichera 2M de pixels avec une impression de 4M de pixels!
Et le tout avec une simplicité qui m'épate encore dans son principe algorythmique (en supposant que j'ai pas tout faux, mais au vu des simulations, y'a pas de raison )
Une restriction cependant: pour un pattern de type échiquier "pur" ces nouvelles puces restitueront une image uniforme. Ma foi, on n'en tiendra pas rigueur à TI .

Je pense que c'est tout bon

Pour une simulation parfaite il faut intégrer la correction de gamma.
- Partir du triplet RGB - gamma 2.2 échelle 0-255
- convertir dans un espace RGB linéaire (gamma 1 échelle 0-4096 pour ne pas perdre de précision)
- faire la somme pixel à pixel (d'où échelle 0-8192)
- reconvertir dans l'espace RGB usuel (échelle 0-8192 vers échelle 0-255 gamma 2.2)

Ouf.

Michel

[MLill]

2 remarques qui se rejoignent sur ta simulation windows:
1: apparition de halo, contour autour des formes (déjà que certain disent que le DLP génére du EE en plus du EE du DVD, si on rajoute encore du EE avec cette méthode, ca va finir par faire beaucoup)
2: apparition de dégradés de couleur: comme s'il fallait avoir une palette de couleur avec 2 fois plus de valeur pour mieux différencier les contours

Il est probable que le traitement du gamma a un impact sur le rendu des contours (si j'ai un peu de temps et beaucoup de courage je le fais à partir des images données par Carlos).

Mais malgré tout le "halo" est la partie "smooth" de l'histoire.
C'est l'inverse de l'EE.
Un dégradé remplace les transitions brusques.
Le EE a pour but au contraire d'accentuer les transitions.
Trop poussé il crée des échos autour de l'image.
Mais même sans le pousser trop on perçoit des "creux" le long des contours.

Michel

[MLill]

Pour essayer d'expliquer cette histoire de gamma.

Si on part d'un de gris de 0.5 de la source (en échelle [0, 1])

Avec un gamma de 2.2 on doit afficher non pas 50 lux pour un blanc à 100 lux mais 22 lux..

La superposition gris-médian noir sera de 11 lux.
La superposition gris médian gris médian de 22 lux.

Ce niveau intermédiaire de 11 lux correspond à 0.36 et non pas à 0.25 dans l'échelle de la source.

En reprenant les premiers exemples de Carlos on retrouve successivement :
- l'image d'origine

- la combinaison obtenue sans tenir compte de la correction de gamma

- la combinaison obtenue en corrigeant le gamma pour simuler complètement le phénomène

L'image est bien plus proche de l'origine mais trop claire.
Ce que l'on peut partiellement corriger.

Qui est de tous les essais, le plus proche visuellement de l'image d'origine.

Comme tout cela joue subtilement sur la colorimétrie (comme le montre la frontière entre les cercles rouge et vert) les ingénieurs de TI ont quand même eu du travail .

Michel

[MLill]

Tu veux parler de la précision du "grand" mirroir ? (il utilisera la même technique que les "petits"?)
J'espère que ça ne sera pas une source supplémentaire de désagréments pour les gens "sensibles" ...

On n'a pas encore d'indication sur le fonctionnement exact du grand miroir mais si je raisonne juste il devrait réduire les désagréments et non pas les augmenter.

Michel

[car_rod]

De fait, si la répartition des pixels en damier semble triviale, une "gestion" colorimétrique est probablement nécessaire pour tenir compte du gamma et de la réduction de la précision colorimétrique.
Rappelons que chaque miroir est responsable de deux pixels, il a ainsi deux fois moins de temps pour s'occuper de chaque pixel. Si artefact il doit y avoir, se sera là (tramage...?).
C'est le deuxième grand défi en plus de la précision optique et mécanique du "grand" miroir additionnel dont on ne sait pas grand chose.

Mon programme crée simplement les images intermédiaires, il ne les combine pas. Justement, si je devais le faire je me contenterais de faire la moyenne . Michel, je te refilerai le code, il fait moins de 300 lignes en C++. A moins que je ne comprenne comment faire une "moyenne" avec un gamma 2.2

L'image finale a été crée avec PaintShopPro (téléchargeable et gratos pendant 30 jours). Un petit coup de transparence à 50%, et hop, c'est fait!

[car_rod]

En relisant le post imagé de MrWigggles sur AVS, je constate qu'il répartit aussi en damier les pixels sur les images intermédiaires, mais je ne trouve pas où il l'explique. On peut quand même lui attribué la primeur de cette répartition
Par contre, dans son exemple de desktop, le résultat est moins beau que le mien :p
http://www.avsforum.com/avs-vb/showthre ... did=394763

[MLill]

En relisant le post imagé de MrWigggles sur AVS, je constate qu'il répartit aussi en damier les pixels sur les images intermédiaires, mais je ne trouve pas où il l'explique. On peut quand même lui attribué la primeur de cette répartition
Par contre, dans son exemple de desktop, le résultat est moins beau que le mien :p
http://www.avsforum.com/avs-vb/showthre ... did=394763

La paternité n'a pas grande importance
Quand une idée est mure on est souvent plusieurs à enchaîner les mêmes raisonnements en parallèle.
Ce qui m'a intéressé c'est la réflexion en réseau qui nous a permis d'aller plus loin et plus vite ensemble qu'isolément.

En ce qui concerne l'enchaînement des réflexions, ma simulation ne dérive que de ton schéma initial et de notre discussion sur les niveaux de gris (7-8 bits).
Je me suis posé la question du gain en résolution en partant de mon expérience "photo" en me disant qu'il y avait une différence entre restitution des lignes et des matrices de 1 pixels.
Le 24 au matin tout était résolu (sauf le point essentiel de l'algorithme à utiliser pour décomposer l'image 1920x1080 en deux images 960x1080).

Je n'ai découvert la simu de Mr Wiggles qu'après avoir posté la mienne.
Avec l'expérience l'erreur sur la taille des pixels m'a sauté aux yeux [edit MLill : sauf que le schéma de MrWiggles est correct donc l'erreur, d'observation, me revient] .
Sans diminuer par 2 le nombre de miroirs on n'explique pas le pourquoi de la distribution en diagonale.

A moins que je ne comprenne comment faire une "moyenne" avec un gamma 2.2

J'ai aussi utilisé PSP pour toutes mes simulations.

Color -> Adjust -> Gamma 0.45
Color -> Ajust -> Curves -> Input (255) Output (127)
Image -> Arithmetic -> Add
Color -> Adjust -> Gamma 2.2

Rappelons que chaque miroir est responsable de deux pixels, il a ainsi deux fois moins de temps pour s'occuper de chaque pixel. Si artefact il doit y avoir, se sera là (tramage...?).

Euh non de 4 pixels.
L'image 1080p a deux fois plus de point image que l'image 1920x1080.

Tous les artefacts numériques classiques que je connais doivent être réduits par rapport au 1920x1080.
Mais sans simu grandeur nature c'est impossible de penser à tout.

Les arcs-en-ciels doivent être réduits :
- frontières moins tranchées
- fréquence pixel multipliée par 2 (comme si l'on multipliait par 2 la vitesse de la roue)

Par contre pour les maux de tête

Michel

[MLill]

Carlos, juste ton image pub hcfr avec un degamma de 2.2 (norme) et un autre de 2.5 (valeur de MrWiggles) - tous traitements faits sous PSP.

2.2


2.5


En faisant des comparaisons d'images bit à bit on repére que les différences sont bien sur les contours.

Michel

[MLill]

Pour mesurer l'impact d'un traitement je pratique les différences d'image amplifiées (avant traitement de compression destructif).
Dans le cas qui nous intéresse entre ton image initiale et l'image corrigée en gamma 2.2 (on repère où il faut regarder).




Michel