hola bunch, i'm new here, i'm scrolling through an extremely long panoramic jpg more of less this way
[pix_image] | [translateXYZ] | [pix_draw]
trouble is translate X clips at ±4, throuwing a black screen, not even a quarter through my jpeg...
any ideas?
oh, and is there a way to plot large image files with [pix_texture]? i'm trying to do something like this: http://shiraklasmerphotography.com/Flash_Move/movement3.htm
grtz, tom
tom tlalim a écrit :
hola bunch, i'm new here, i'm scrolling through an extremely long panoramic jpg more of less this way
[pix_image] | [translateXYZ] | [pix_draw]
trouble is translate X clips at ±4, throuwing a black screen, not even a quarter through my jpeg...
any ideas?
use : gemhead translateXYZ pix_image pix_texture rectangle 20 2
cyrille
oh, and is there a way to plot large image files with [pix_texture]? i'm trying to do something like this: http://shiraklasmerphotography.com/Flash_Move/movement3.htm
grtz, tom
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 2007-11-10 at 22:23 +0100, cyrille henry wrote:
tom tlalim a écrit :
hola bunch, i'm new here, i'm scrolling through an extremely long panoramic jpg more of less this way
[pix_image] | [translateXYZ] | [pix_draw]
trouble is translate X clips at ±4, throuwing a black screen, not even a quarter through my jpeg...
any ideas?
use : gemhead translateXYZ pix_image pix_texture rectangle 20 2
i am surprised, that you got even a result with [translateXYZ]-[pix_draw]. something very important to know about Gem is, that you can work in two domains: in the openGl-domain, which is completely processed on the gpu (if supported by hardware and enabled) and in the pix domain, which is computed on the cpu. all objects of gem with pix_* in their name belong to the pix domain. what cyrilly is proposing , is to switch as soon as possible to the opengl domain in order to save cpu, since [pix_draw] usually is quite slow (with [pix_draw] you get the very same result while just burning some cpu cycles).
cyrille
oh, and is there a way to plot large image files with [pix_texture]? i'm trying to do something like this: http://shiraklasmerphotography.com/Flash_Move/movement3.htm
yeah, this is perfectly possible with the patch, that cyrille proposed. nevertheless, there are probably some hardware limitations. at least on my box, i wasn't able to texture a picture with a width of 3000px. i splitted it into 3 files à 1000px and textured them separately on three rectangles. let me know, if cannot figure out to do it, i can send you the patch.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On 11 Nov 2007, at 3:43 PM, Roman Haefeli wrote:
use : gemhead translateXYZ pix_image pix_texture rectangle 20 2
i am surprised, that you got even a result with [translateXYZ]-[pix_draw]. something very important to know about Gem is, that you can work in two domains: in the openGl-domain, which is completely processed on the gpu (if supported by hardware and enabled) and in the pix domain, which is computed on the cpu. all objects of
gem with pix_* in their name belong to the pix domain. what cyrilly is proposing , is to switch as soon as possible to the opengl domain in order to save cpu, since [pix_draw] usually is quite slow (with [pix_draw] you get the very same result while just burning some cpu cycles).cyrille
oh, and is there a way to plot large image files with [pix_texture]? i'm trying to do something like this: http://shiraklasmerphotography.com/Flash_Move/movement3.htm
yeah, this is perfectly possible with the patch, that cyrille
proposed. nevertheless, there are probably some hardware limitations. at
least on my box, i wasn't able to texture a picture with a width of 3000px. i splitted it into 3 files à 1000px and textured them separately on
three rectangles. let me know, if cannot figure out to do it, i can send you the patch.
the hardware limitation that I know of is the graphics card memory
(that limits the max size any textures can be) - the way I've got
around that in a more general way is splitting long images into
separate 4x3 files and using an abstraction with two gemheads,
alternating between the smaller files - I could also post that if you
wanted.
simon
thnx. i've already started working on a prototype for multiple files, but it would be an excellent time saver to see both your implementations.
grtz, tom
On Nov 12, 2007 2:35 AM, simon wise simonxwise@hotmail.com wrote:
On 11 Nov 2007, at 3:43 PM, Roman Haefeli wrote:
use : gemhead translateXYZ pix_image pix_texture rectangle 20 2
i am surprised, that you got even a result with [translateXYZ]-[pix_draw]. something very important to know about Gem is, that you can work in two domains: in the openGl-domain, which is completely processed on the gpu (if supported by hardware and enabled) and in the pix domain, which is computed on the cpu. all objects of gem with pix_* in their name belong to the pix domain. what cyrilly is proposing , is to switch as soon as possible to the opengl domain in order to save cpu, since [pix_draw] usually is quite slow (with [pix_draw] you get the very same result while just burning some cpu cycles).
cyrille
oh, and is there a way to plot large image files with [pix_texture]? i'm trying to do something like this: http://shiraklasmerphotography.com/Flash_Move/movement3.htm
yeah, this is perfectly possible with the patch, that cyrille proposed. nevertheless, there are probably some hardware limitations. at least on my box, i wasn't able to texture a picture with a width of 3000px. i splitted it into 3 files à 1000px and textured them separately on three rectangles. let me know, if cannot figure out to do it, i can send you the patch.
the hardware limitation that I know of is the graphics card memory (that limits the max size any textures can be) - the way I've got around that in a more general way is splitting long images into separate 4x3 files and using an abstraction with two gemheads, alternating between the smaller files - I could also post that if you wanted.
simon
On 12 Nov 2007, at 1:06 PM, tom tlalim wrote:
thnx. i've already started working on a prototype for multiple files, but it would be an excellent time saver to see both your
implementations.
here is a patch for scrolling wide images across the screen, it is
part of a bigger, more general system so there are lots of extra bits
in there
put all 4 patches and 4x3 image files named image-1.png, image-2.png,
image-3.png in the same folder and open scroll-tiles-help.pd ...
simon
ah, nice one - thanx! great idea to load image parts while scrolling! this enables panoramas of different lengths. the only issue is i get a little jump in scrolling speed when new files get loaded (mine are 1500 X 425 ±400k each)
grtz, t
On Nov 12, 2007 4:01 PM, simon wise simonxwise@hotmail.com wrote:
On 12 Nov 2007, at 1:06 PM, tom tlalim wrote:
thnx. i've already started working on a prototype for multiple files, but it would be an excellent time saver to see both your implementations.
here is a patch for scrolling wide images across the screen, it is part of a bigger, more general system so there are lots of extra bits in there
put all 4 patches and 4x3 image files named image-1.png, image-2.png, image-3.png in the same folder and open scroll-tiles-help.pd ...
simon
On 13 Nov 2007, at 8:35 AM, tom tlalim wrote:
ah, nice one - thanx! great idea to load image parts while scrolling! this enables panoramas of different lengths. the only issue is i get a little jump in scrolling speed when new files get loaded (mine are 1500 X 425 ±400k each)
yes - it depends on your machine, if it is fast enough then you can
get away with loading without it being too noticeable, otherwise to
get it smooth on a slower machine you need to have multiple
[pix_image] objects and load them all first. Depending on the desired
results you can play around with the [gemwin] rate and with the
resolution and compression of your image files (different codecs may
load faster, no compression could be an advantage and Gem scales
lower resolutions up quite nicely). You could also try tricks like
making a ramdisk to hold the files in ram - then loading them to the
GPU could be faster but I haven't needed to go down that path yet. It
is possible that you could do the file reading/texturing happen in
one instance of pd with a lower priority and pass the texture ID
across to another pd which does the playing - but this may just be
fantasy and I certainly haven't tried it.
What I have generally done for performances is make sure nothing
unnecessary is running on the machines that run the video mixing
patch, and running pd -nogui controlling everything via a midi fader
desk or from a pd control patch on another computer on the network.
This has worked well for me running video clips, live camera and
still images on several screens from 1 controller.
simon
yo.
thnx for all your help & education. i feel ready to take it from here. pd is a powerful tool no dubt.
my performance issue is probably due to the macbook having a not-so great video card. i'll try different compressions or jus load the whole bulk.
till next time, tom
On Nov 13, 2007 1:17 AM, simon wise simonxwise@hotmail.com wrote:
On 13 Nov 2007, at 8:35 AM, tom tlalim wrote:
ah, nice one - thanx! great idea to load image parts while scrolling! this enables panoramas of different lengths. the only issue is i get a little jump in scrolling speed when new files get loaded (mine are 1500 X 425 ±400k each)
yes - it depends on your machine, if it is fast enough then you can get away with loading without it being too noticeable, otherwise to get it smooth on a slower machine you need to have multiple [pix_image] objects and load them all first. Depending on the desired results you can play around with the [gemwin] rate and with the resolution and compression of your image files (different codecs may load faster, no compression could be an advantage and Gem scales lower resolutions up quite nicely). You could also try tricks like making a ramdisk to hold the files in ram - then loading them to the GPU could be faster but I haven't needed to go down that path yet. It is possible that you could do the file reading/texturing happen in one instance of pd with a lower priority and pass the texture ID across to another pd which does the playing - but this may just be fantasy and I certainly haven't tried it.
What I have generally done for performances is make sure nothing unnecessary is running on the machines that run the video mixing patch, and running pd -nogui controlling everything via a midi fader desk or from a pd control patch on another computer on the network. This has worked well for me running video clips, live camera and still images on several screens from 1 controller.
simon
-
cyrille henry -
Roman Haefeli -
simon wise -
tom tlalim