[PD] Recommendations for combining many images (256+)
B. Bogart
ben at ekran.org
Sat Sep 20 18:05:12 CEST 2008
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 at ekran.org
> <mailto:ben at 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 at iem.at <mailto:Pd-list at iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
More information about the Pd-list
mailing list