Hey all,
Any recommendations as to the best way to combine many images?
What I'm after is a kind of long exposure where each image could be weighted differently in order to give it more emphasis.
I did a quick test in Gem layering 100 images on 100 rects on top of one and other with 0.01 opacity.
Problem it uses too much CPU (seems to be the GPU lagging). I can render all 100 easily on the same machine if they are not totally overlapping.
Would gridflow be able to combine 256 640x480 images?
CPU solutions (rather than GPU) are best, as I'm hoping for 640x480 resolution and many more images than will fit in graphics mem.
Would something like this work:
Every channel of every pixel of every image divided by the number of images (256) multiplied by a weight, where all the results are summed?
All the images would be loaded into a pix_buffer.
What is the best way to accomplish this?
Thanks,
.b.
Have you tried single buffer rendering? If you don't need 30fps performance you could layer the images with opacity using only one pix_texture object and very little GPU memory.
On Fri, Sep 19, 2008 at 3:59 PM, B. Bogart ben@ekran.org wrote:
Hey all,
Any recommendations as to the best way to combine many images?
What I'm after is a kind of long exposure where each image could be weighted differently in order to give it more emphasis.
I did a quick test in Gem layering 100 images on 100 rects on top of one and other with 0.01 opacity.
Problem it uses too much CPU (seems to be the GPU lagging). I can render all 100 easily on the same machine if they are not totally overlapping.
Would gridflow be able to combine 256 640x480 images?
CPU solutions (rather than GPU) are best, as I'm hoping for 640x480 resolution and many more images than will fit in graphics mem.
Would something like this work:
Every channel of every pixel of every image divided by the number of images (256) multiplied by a weight, where all the results are summed?
All the images would be loaded into a pix_buffer.
What is the best way to accomplish this?
Thanks,
.b.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Chris,
I have used SB before for this, but in this case I need more flexibility (and the images should not build up over time but be combined from the first frame.
Seems like I may have to delve into some C++ to do the math manually. Will that be too slow though? iterating over the data in a pix_buffer should be fast right?
If anyone has some sample code along these lines please let me know.
B. Bogart
chris clepper wrote:
Have you tried single buffer rendering? If you don't need 30fps performance you could layer the images with opacity using only one pix_texture object and very little GPU memory.
On Fri, Sep 19, 2008 at 3:59 PM, B. Bogart <ben@ekran.org mailto:ben@ekran.org> wrote:
Hey all, Any recommendations as to the best way to combine many images? What I'm after is a kind of long exposure where each image could be weighted differently in order to give it more emphasis. I did a quick test in Gem layering 100 images on 100 rects on top of one and other with 0.01 opacity. Problem it uses too much CPU (seems to be the GPU lagging). I can render all 100 easily on the same machine if they are not totally overlapping. Would gridflow be able to combine 256 640x480 images? CPU solutions (rather than GPU) are best, as I'm hoping for 640x480 resolution and many more images than will fit in graphics mem. Would something like this work: Every channel of every pixel of every image divided by the number of images (256) multiplied by a weight, where all the results are summed? All the images would be loaded into a pix_buffer. What is the best way to accomplish this? Thanks, .b. _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You could write an object like pix_buffer_mix that made a composite out of all of the frames. Look at pix_mix for the basic RGBA and YUV loops and then wrap a loop around that while moves over each frame in the buffer. This will not be all that fast and doubtfully run at 30fps with hundreds of images in the buffer.
On Sat, Sep 20, 2008 at 11:05 AM, B. Bogart ben@ekran.org wrote:
Hi Chris,
I have used SB before for this, but in this case I need more flexibility (and the images should not build up over time but be combined from the first frame.
Seems like I may have to delve into some C++ to do the math manually. Will that be too slow though? iterating over the data in a pix_buffer should be fast right?
If anyone has some sample code along these lines please let me know.
B. Bogart
-
B. Bogart -
chris clepper