hi list -
It would be really great if someone could shed some light on this issue.
i'm trying to merge some pics with the pix_composite object. now, instead of using [t a a a a a ...] and (numberofpics - 1) pix_composites (simply enough - got it to work), i tried to do it in a less clumsy and cpu-demanding way by using pix_buffer. my idea was to read all images into a buffer first (say, into slots 0-7) and mix them afterwards (using slot 8). The actual mixing would be some sort of iteration: first the images in slot 1 (left inlet of Pix_composite) and 0 (right one) will be mixed into slot 8. Afterwards slot 2 (left) and slot 8 (right) are mixed to slot 8, the same would be done with slots 3 to 7 ... This actually works, the only drawback is that the mixed pics are not only written to slot #8, but to the currently processed slot as well. Although the only pix_buffer_write object in the whole patch gets an [8( banged to its right inlet everytime a render cycle occurs. This sounds probably a bit confusing ... please have a look at the attached patch, that should make it more obvious.
thank you in advance, thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Hey there,
I don't have time to look at your patch but I have some ideas.
I guess your mixing still images?
the BEST way to do this in Gem is to make a different square/rectangle for each image and stack them on top of one and other then gemhead 1 in the back and gemhead N in the front. Then you just use the alpha blending to make the mix. This is much more simple, much easier, and way way more optimized.
Let me know if this approach does not work for your concept.
B>
hi list -
It would be really great if someone could shed some light on this issue.
i'm trying to merge some pics with the pix_composite object. now, instead of using [t a a a a a ...] and (numberofpics - 1) pix_composites (simply enough - got it to work), i tried to do it in a less clumsy and cpu-demanding way by using pix_buffer. my idea was to read all images into a buffer first (say, into slots 0-7) and mix them afterwards (using slot 8). The actual mixing would be some sort of iteration: first the images in slot 1 (left inlet of Pix_composite) and 0 (right one) will be mixed into slot 8. Afterwards slot 2 (left) and slot 8 (right) are mixed to slot 8, the same would be done with slots 3 to 7 ... This actually works, the only drawback is that the mixed pics are not only written to slot #8, but to the currently processed slot as well. Although the only pix_buffer_write object in the whole patch gets an [8( banged to its right inlet everytime a render cycle occurs. This sounds probably a bit confusing ... please have a look at the attached patch, that should make it more obvious.
thank you in advance, thoralf.
Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
Ben,
the BEST way to do this in Gem is to make a different square/rectangle for each image and stack them on top of one and other
sounds promising - unfortunately, this approach doesn't fit into the framework of the thingie i want to use this patch for (a vj-tool). it's based on input->filter->output-chains, and their interconnections are one and only one gem-renderchain. I would have to do rendering in the input-part and make snapshots there, and i'm somewhat reluctant to do so ...
make the mix. This is much more simple, much easier, and way way more optimized.
then again, this sounds convincing. hmm. at the moment i'm tempted to screw my approach and do the mixing in a really dull and ugly (but working) way
- buffered with (number of pics-1) pix_composite
objects.
with kind regards, thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Hey Thoralf,
Indeed my system does not fit well into input->filter->output, but then again neither does Gem. Now this is how PDP is designed and worked very well for doing this.
I'm developing PixelTANGO which is a Gem-based VJ tool and I have run into many of the issues your talking about. I would argue that if you want to make effective use of gem forget your input->filter->output idea or use PDP.
That being said I don't see anything in your project (mixing images) that is dependant on this idea.. Or am I missing something? You must be doing much more than just mixing images... ?
I have used pix_composite but it was pretty damn slow (on linux) no chance for GPU optimization, since the work in done on the CPU and then passed onto the graphics card for the easy part, putting it on an object.
Anyhow good luck!
B>
Ben,
the BEST way to do this in Gem is to make a different square/rectangle for each image and stack them on top of one and other
sounds promising - unfortunately, this approach doesn't fit into the framework of the thingie i want to use this patch for (a vj-tool). it's based on input->filter->output-chains, and their interconnections are one and only one gem-renderchain. I would have to do rendering in the input-part and make snapshots there, and i'm somewhat reluctant to do so ...
make the mix. This is much more simple, much easier, and way way more optimized.
then again, this sounds convincing. hmm. at the moment i'm tempted to screw my approach and do the mixing in a really dull and ugly (but working) way
- buffered with (number of pics-1) pix_composite
objects.
with kind regards, thoralf.
Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Hi Ben,
thank you for your answer. you got it quite right: the tool i'm hacking together atm is indeed a little more than just blending images: inputs can be still images, movie clips, live video streams and probably some other stuff as well. each of these inputs has a filter chain assigned to it (various pix_objects) and will then be rendered on some sort of geo (the few gem provides plus 3d objects, oscilloscopes, spectrum analysers and so on). The rough idea is that everything can be done to anything, the result can then be rendered on any of the geos. so basically it's mainly kicking messages around: draw the motion-blurred input from the video scratcher on a cube whose size depends on the amount of bass in the music and the like. i resort to a midi controller to manage this mess, although plain clicking is also possible.
And yeah, I ran into several limitations of this concept already (mixing chains doesn't fit into it, for example, feedback would also be quite a hack), but i want to finish it for the sake of having it done :-) I already had a quick look at pdp - looked very promising. some things keep me from switching to linux at the moment (neither midi nor tv out is working atm, searchin and compiling missing libs is almost always a pita, etc.), but i will do this sooner or later.
I'll have a look at your pixelTango - it was linux only the last time i checked :-)
all the best, thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Hey Thoralf,
I'm still not hearing of any reason for keeping your images in one gem-chain. This could be just because of the problem of overlapping 3D geos? (5 cubes of the same size and position, and doing blending with alpha values.) Due to the render order of the faces this could not be the result your looking for.
Anyhow dynamic gem-chains are very possible and allow a lot of possibilities.
PixelTANGO is linux and OSX, but it *should* work in Windows, just a matter of getting the right externals and setting up the path and such. One day it'll work well, with the guy who touches windows gets to it. ;)
Hope you put some videos up. B.
Thoralf Schulze wrote:
Hi Ben,
thank you for your answer. you got it quite right: the tool i'm hacking together atm is indeed a little more than just blending images: inputs can be still images, movie clips, live video streams and probably some other stuff as well. each of these inputs has a filter chain assigned to it (various pix_objects) and will then be rendered on some sort of geo (the few gem provides plus 3d objects, oscilloscopes, spectrum analysers and so on). The rough idea is that everything can be done to anything, the result can then be rendered on any of the geos. so basically it's mainly kicking messages around: draw the motion-blurred input from the video scratcher on a cube whose size depends on the amount of bass in the music and the like. i resort to a midi controller to manage this mess, although plain clicking is also possible.
And yeah, I ran into several limitations of this concept already (mixing chains doesn't fit into it, for example, feedback would also be quite a hack), but i want to finish it for the sake of having it done :-) I already had a quick look at pdp - looked very promising. some things keep me from switching to linux at the moment (neither midi nor tv out is working atm, searchin and compiling missing libs is almost always a pita, etc.), but i will do this sooner or later.
I'll have a look at your pixelTango - it was linux only the last time i checked :-)
all the best, thoralf.
Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Thoralf Schulze wrote:
hi list -
This actually works, the only drawback is that the mixed pics are not only written to slot #8, but to the currently processed slot as well. Although the only pix_buffer_write object in the whole patch gets an [8( banged to its right inlet everytime a render cycle occurs.
most pixel-effects (that allow it) di image-manipulation _in place_ . this means that the (left side) image of an effect is overwritten.
this explaings why your "source data" changes as well. you can use [pix_buf] to decouple the image source from the effect.
apart from that, ben is right, that Gem is probably not the best available platform for such kind of things.
mfg.adr IOhannes
hi iohannes,
you can use [pix_buf] to decouple the image source from the effect.
Yeah, I was probably missing this (cannot check right now). Thanks for clearing this up.
apart from that, ben is right, that Gem is probably not the best available platform for such kind of things.
But working with win atm, i don't have much of a choice ... The only really bad thing in my opinion is that all gem-objects are tied to gem render messages, and having them decoupled would be quite handy every now and then. I guess that pdp / pidip are kicking in at exactly this point ...
thank you, thoralf.
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
-
B. Bogart -
IOhannes m zmoelnig -
Thoralf Schulze