Dear list, I am using high speed cameras with 200fps. Is there any hard coded limitation in Gem which determines maximum fps? or [frame 200( to [gemwin] is enough? I tried [metro 5] to [gemhead] too, but need a proof that it goes 200fps. Does any of you have a patch which could measure the fps in gemwin? I found something on the forum but not sure if it does the job for me.
Looking forward to some advice,
Popesz
On 2018-09-05 12:26, Csaba Láng wrote:
Dear list, I am using high speed cameras with 200fps. Is there any hard coded limitation in Gem which determines maximum fps?
no
or [frame 200( to [gemwin] is enough?
no
I tried [metro 5] to [gemhead] too, but need a proof that it goes 200fps. Does any of you have a patch which could measure the fps in gemwin?
measure the time between two render-ticks with [realtime].
anyhow: the problem you are facing is, that Gem uses openGL to render to the [gemwin]. depending on the driver and your driver settings, the openGL render buffer might only be swapped while the screen is being blanked ("sync-to-vblank"), to avoid tearing. if this is enabled, this means that for each render-tick, Gem (well, rather the underlying openGL engine) will wait for a vblank until the render-tick can be executed. the vblank happens whenever the screen is refreshed. if your screen has a refresh-rate of 97Hz, then the effective (maximum) frame-rate of the [gemwin] will be 97fps - regardless of what framerate you requested for the [gemwin] (via argument, or via the [frame( message). (pick *your* actual screen refresh rate). also, if the screen framerate is not an integer multiple of your chosen Gem-framerate, you might get weird resampling artifacts in the render timing.
however, the only operations affected by this are openGL operations. these include all objects that draw to the screen (e.g. [square]), or manipulate the drawings (e.g. [rotate]) or the framebuffer ([gemframebuffer], [glsl_program], [pix_texture])
on the other side, objects that do not interact with the openGL engine, are not directly affected. most importantly, grabbing image data ([pix_image], [pix_video],...), storing image data ([pix_buffer...]) and manipulating image data ([pix_gain], [pix_kaleidoscope], [pix_multiblob],...) has nothing to do with openGL and is therefore unaffected by sync-to-vblank.
at least in theory. because when running a normal Gem-patch, the [pix_...] objects are driven (aka: triggered) by [gemwin], which (as it interacts with the openGL engine) is bound by sync-to-vblank.
however: if (and only if) you have a [gemhead] that is only triggering non-openGL objects (e.g. *only* [pix_...]es), then you can manually trigger *this* gem-chain via a [metro], running at an arbitrary rate. (you should turn off the automatic-triggering of this [gemhead] by sending it a "0"),
I found something on the forum but not sure if it does the job for me.
i found something in my washbasin, but i don't know how much i can charge for it.
hgmasd rIOhannes
Iohannes,
thanks for your advice. However I forgot to add that the 200fps I would like to use is not for displaying, but mostly to analyse fast objects in front of the camera. the chain would look like this: [0( and [metro 5( | [gemhead] | [pix_video] with videoPYLON plugin [pix_multiblob]
no pix_texture needed for video render, I use only the coordinates of the centre of gravity. Theoretically, it should use the capacity frame rate of the USB3 cameras, should not it?
Best, Popesz
On Wed, Sep 5, 2018 at 1:56 PM IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2018-09-05 12:26, Csaba Láng wrote:
Dear list, I am using high speed cameras with 200fps. Is there any hard coded limitation in Gem which determines maximum fps?
no
or [frame 200( to [gemwin] is enough?
no
I tried [metro 5] to [gemhead] too, but need a proof that it goes 200fps. Does any of you have a patch which could measure the fps in gemwin?
measure the time between two render-ticks with [realtime].
anyhow: the problem you are facing is, that Gem uses openGL to render to the [gemwin]. depending on the driver and your driver settings, the openGL render buffer might only be swapped while the screen is being blanked ("sync-to-vblank"), to avoid tearing. if this is enabled, this means that for each render-tick, Gem (well, rather the underlying openGL engine) will wait for a vblank until the render-tick can be executed. the vblank happens whenever the screen is refreshed. if your screen has a refresh-rate of 97Hz, then the effective (maximum) frame-rate of the [gemwin] will be 97fps - regardless of what framerate you requested for the [gemwin] (via argument, or via the [frame( message). (pick *your* actual screen refresh rate). also, if the screen framerate is not an integer multiple of your chosen Gem-framerate, you might get weird resampling artifacts in the render timing.
however, the only operations affected by this are openGL operations. these include all objects that draw to the screen (e.g. [square]), or manipulate the drawings (e.g. [rotate]) or the framebuffer ([gemframebuffer], [glsl_program], [pix_texture])
on the other side, objects that do not interact with the openGL engine, are not directly affected. most importantly, grabbing image data ([pix_image], [pix_video],...), storing image data ([pix_buffer...]) and manipulating image data ([pix_gain], [pix_kaleidoscope], [pix_multiblob],...) has nothing to do with openGL and is therefore unaffected by sync-to-vblank.
at least in theory. because when running a normal Gem-patch, the [pix_...] objects are driven (aka: triggered) by [gemwin], which (as it interacts with the openGL engine) is bound by sync-to-vblank.
however: if (and only if) you have a [gemhead] that is only triggering non-openGL objects (e.g. *only* [pix_...]es), then you can manually trigger *this* gem-chain via a [metro], running at an arbitrary rate. (you should turn off the automatic-triggering of this [gemhead] by sending it a "0"),
I found something on the forum but not sure if it does the job for me.
i found something in my washbasin, but i don't know how much i can charge for it.
hgmasd rIOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2018-09-05 14:10, Csaba Láng wrote:
Iohannes,
thanks for your advice. However I forgot to add that the 200fps I would like to use is not for displaying, but mostly to analyse fast objects in front of the camera.
i think i covered this use-case in length.
Theoretically, it should use the capacity frame rate of the USB3 cameras, should not it?
relate this to:
On Wed, Sep 5, 2018 at 1:56 PM IOhannes m zmoelnig zmoelnig@iem.at wrote:
most importantly, grabbing image data ([pix_image], [pix_video],...), storing image data ([pix_buffer...]) and manipulating image data ([pix_gain], [pix_kaleidoscope], [pix_multiblob],...) has nothing to do with openGL and is therefore unaffected by sync-to-vblank.
[...]
if (and only if) you have a [gemhead] that is only triggering non-openGL objects (e.g. *only* [pix_...]es), then you can manually trigger *this* gem-chain via a [metro], running at an arbitrary rate. (you should turn off the automatic-triggering of this [gemhead] by sending it a "0")
i think, the keyword here is "arbitrary".
gmfasdr IOhannes
-
Csaba Láng -
IOhannes m zmoelnig