Tu as aussi la possibilité d'utiliser [gemframebuffer] qui copie le rendu global dans une texture, à tester.

Bon... ça ne marche pas vraiment tout ça...
En gros je veux faire la capture de l'image affichée dans la fenêtre GEM et qui provient de plusieurs [gemhead] et stocker ça dans un [pix_buffer] pour être relu à la demande, plus tard.

De ce que j'ai compris de [gemframebuffer], c'est que ça fait un rendu dans un espace virtuel et ça applique cette image comme un texture sur un objet de la fenêtre réelle.

[gems.loop] attend un flux vidéo et capture les images de cette source. Pas moyen de l'utiliser tel quel pour capturer à partir de plusieurs [gemhead].

J'ai aussi testé [pix_snap] sans résultat. A part qu'à chaque [snap( on a l'image qui disparaît dans la fenêtre de GEM. Voir patch en fichier joint. (il manque un [pix_texture] entre le [pix_buffer_read] et la suite...)


D'autres suggestions ? Un combinaison de ces objets ?
Merci.

Dernière modification par pob (2009-12-20 01:00:27)

Merci pour l'encouragement !

Il y a [pix_record] aussi dans la liste des objets.
Je voudrais autant que possible pouvoir stocker image par image pour des histoires de relectures (boucles) de façon simple.
J'ai vu une approche différente : un seul [gemhead] avec un [t a a a a ... a] qui le distribue à toutes les branches de rendu avec un ordre spécifique et ensuite avec des [separator] ou [pix_separator] si besoin pour isoler les transformations et les traintements... C'était dans un vieux message sur la pd-list, alors c'est peut-être remplacé par l'argument dans l'objet [gemhead].

Pour enregistrer la fenêtre je crois que je peux le faire avec un logiciel de capture d'écran, voire avec VLC.

Je vais bien finir par trouver une solution...

Oui, j'ai testé le patch de IOhannes et un autre de Jack. Il faut que je regarde un peu mieux. Mais si j'ai bien compris, ça reviendrait à faire tous les rendus des différentes branches dans le [gemframebuffer] et en sortie l'appliquer à un geos pour l'affichage et le capturer par [pix_snap] sans sortir du framebuffer.
Je vais m'y pencher sur une version à petite échelle avant de passer à la version plus chargée. Ca fait une belle reconstruction du patch d'origine, mais si c'est la solution en quelques heures c'est réglé.

Dernière modification par pob (2009-12-20 00:58:31)

J'ai passé une bonne partie de la journée à essayer de faire marcher [pix_snap]... Je ne sais pas si je vais vraiment m'entêter. Dans le petit patch que j'ai mi plus tôt, il manquait un [pix_texture]. Mais ça n'a pas résolu pour autant mes problèmes. J'ai testé avec un autre [pix_buffer] déjà chargé, la lecture marche. Ce qui cloche, c'est la capture.
Déjà ça ralentit grave l'affichage, jusqu'à bloquer entièrement la machine si je le sollicite trop pendant la capture. De ce que j'ai lu, les transferts sont bien plus rapides entre RAM et carte graphique que dans le sens inverse. C'est pas prévu pour ça. En tout cas sur mon petit chipset GMA, c'est un gros effort. Je vais tester ça sur une tour un peu plus puissante pour voir... C'est pas un monstre, mais ce sera sans doute toujours mieux.

Mais si c'était que le ralentissement... le buffer ne stocke rien, rien de rien. J'ai d'abord utilisé plusieurs [gemhead].
J'ai ensuite tenté de faire avec un seul [gemhead] distribué par un trigger ( [t a a ... a] ). Ca n'a rien changé là non-plus. Par contre les différentes branches n'entraient pas dans le [pix_snap] mais étaient envoyées en texture sur une batterie de rectangles.
Le fichier d'aide de [pix_snap] recommande de ne l'utiliser qu'avec un affichage à un seul framebuffer.
J'ai aussi lu qu'il y avait une position pour le [pix_snap] (genre en coordonnées cartésiennes 0 0 0) alors que le plan de la fenêtre [gemhead] est en (0 0 -4). Alors j'ai testé avec diverses translation, sans succès là non-plus.

Reste maintenant la solution d'un [gemframebuffer]. Autrement j'oublierai cette idée de faire des auto-citations à court terme...

Salut, j'ai fait un simple essais avec [pix_snap] qui sample ce qui se passe à l'écran. Ça à l'air de bien marcher, le flux provient juste de la webcam composé en un triptyque afin d'avoir une source composé et faire le test rapidement.

Le patch est attaché...

pob a écrit:

Par contre aujourd'hui, solstice d'hiver, fête païenne pour pratiquant du sténopé, on change nos solarographes. Au programme scan, remise en état de sténopé restant de mois à l'extérieur et rechargement.

WAOU alors la respect !
Ces prises de plusieurs mois captant la course du soleil sont magnifiques.
Ayant été fan de sténopé j'en été resté à exposer mes boites quelques heures au plus, effaçant le mouvement des gens dans les rues....
Mais, la, à l'occasion, il va falloir que je revois ces dispositifs.
Hâte de voir tes prises de vues !