karl krach

today i got a point grey chameleon 3 camera which provides up to 150fps (@1280x1024) over usb3. after some fumbeling around i did get it to work in max but i only get 80fps tops. in point grey's flycapture app, i get very solid 150fps so usb bandwidth/hardware seems not to be the problem.

does anyone happen to have any experience with this camera in jitter?

or on a broader level, experience with capturing high framerates in general?

hi everybody,
today i got a point grey chameleon 3 camera which provides up to 150fps (@1280x1024) over usb3. after some fumbeling around i did get it to work in max but i only get 80fps tops. in point grey's flycapture app, i get very solid 150fps so usb bandwidth/hardware seems not to be the problem.
does anyone happen to have any experience with this camera in jitter?
or on a broader level, experience with capturing high framerates in general?

any insights are highly appreciated!
karl


150fps-with-ptgrey-chameleon-3-camera

update: i spent some more time with this and now i'm at about 105fps. these 105fps i can confirm visually.

the thing which confuses me quite a bit though and what might help find the bottleneck:

- when i set @unique 1, i get the 105fps, but also reports of dropped frames.

- however when i disable @unique, i can bump up the metro and the matrixes are output at full speed (!) - only that these matrixes now double since the camera does not deliver fresh images.

- regardless i still get reports of dropped frames - until i crank the metro up to "6" - which is just above the 150fps the camera should deliver.

what i make out of this: the system does understand the camera runs at 150fps. also my patch is capable of putting out and processing matrixes at that speed. so the bottleneck really seems to be within dx.grab...?

can anyone shed some light onto this? again, thanks a lot for any help!

for reference: i run max 7.2.2, 64bit, viddl on windows 10. dx.grab is set to uyvy.

the thing which confuses me quite  a bit though and what might help find the bottleneck:
- when i set @unique 1, i get the 105fps, but also reports of dropped frames.
- however when i disable @unique, i can bump up the metro and the matrixes are output at full speed (!) - only that these matrixes now double since the camera does not deliver fresh images.
- regardless i still get reports of dropped frames - until i crank the metro up to "6" - which is just above the 150fps the camera should deliver.

can anyone shed some light onto this? again, thanks a lot for any help!
karl

for reference: i run max 7.2.2, 64bit, viddl on windows 10. dx.grab is set to uyvy.


is this a bug of jit.dx.grab and should i file a bug report?

is there any _proven_ setup that is able to deliver 150fps+, maybe with another camera?

(i could still return the chameleon 3 if the problem should really be the camera but as explained above, to me it seems the culprit is dx.grab...)

again, any help is would be really appreciated!

noone?
is this a bug of jit.dx.grab and should i file a bug report?
or is my conclusion wrong?
is there any _proven_ setup that is able to deliver 150fps+, maybe with another camera?
(i could still return the chameleon 3 if the problem should really be the camera but as explained above, to me it seems the culprit is dx.grab...)

again, any help is would be really appreciated!
k


hi Karl, time ago i was working with a PGR camera having as you some issues to get the right framerate.

https://cycling74.com/forums/pgr-fireflymv-libdc1394-mbp-osx-10-8-2

maybe this helps: https://cycling74.com/forums/pgr-fireflymv-libdc1394-mbp-osx-10-8-2

150 fps, is there any reason you need to run things that fast ? An average computer game is between 60-90 fps, more than that isn't noticeable to the human eye.

For speed increases have you tried converting your camera input to a texture (with jit.gl.texture) ?

Processing and analysis could then be done with jit.gl.pix or jit.gen. For video analysis its standard to use a lower resolution video for speed.

Qmetro is better for video than metro as it allows dropped frames. Dropped frames are only a problem if you notice them right ?

Maybe if you make clear what your goal is it'll be easier to advise you on how to optimise your patch.

Have you tried running your patch in presentation mode so that no GUI elements are drawn ? Float boxes, message boxes, they all hog the GPU when theres a lot on screen.

150 fps, is there any reason you need to run things that fast ? An average computer game is between 60-90 fps, more than that isn't noticeable to the human eye.
For speed increases have you tried converting your camera input to a texture (with jit.gl.texture) ?
Processing and analysis could then be done with jit.gl.pix or jit.gen. For video analysis its standard to use a lower resolution video for speed.
Qmetro is better for video than metro as it allows dropped frames. Dropped frames are only a problem if you notice them right ?
Maybe if you make clear what your goal is it'll be easier to advise you on how to optimise your patch.
Have you tried running your patch in presentation mode so that no GUI elements are drawn ? Float boxes, message boxes, they all hog the GPU when theres a lot on screen.


i tried some more things including everything mentioned but unfortunately did not get any further, i do not get beyond about 100fps.

the background is, i do not play back at this high framerates but save the images to a jit.matrixset i use as a buffer, then read them back later at slower speeds and only then i port the images to the gpu. if i do not use the camera as input but a still image, my patch can do this at like 300fps easily so apart jit.grab, everything seems to work pretty nicely...

also, i made a new patch with only the camera, same results. the resolution does not seem to be much of an issue either - even if i bump that up to the double or reduce it by half, results are still almost the same. neither does the video engine (qt/viddl) or using jit.qt.grab instead of dx.grab do anything. apart, cpu/gpu/mem/etc. usage is pretty low, eg. cpu ranging about 20%.

what might be interesting: switching the colormode to argb makes things slower - with uyvy i get 100fps, with argb only about 75. also i revisited the weird behaviour of @unique and @dropreport explained in the second post but i could not reproduce it - right now they both act consistent (behaving like the camera would deliver about 105fps).

to me it really seems like if jit.dx.grab just wasn't programmed to deliver anything higher than 100fps... is that the case? or is there any other route i could try?

hey you two,
thank you very much for your help!
i tried some more things including everything mentioned but unfortunately did not get any further, i do not get beyond about 100fps.

the background is, i do not play back at this high framerates but save the images to a jit.matrixset i use as a buffer, then read them back later at slower speeds and only then i port the images to the gpu. if i do not use the camera as input but a still image, my patch can do this at like 300fps easily so apart jit.grab, everything seems to work pretty nicely...
also, i made a new patch with only the camera, same results. the resolution does not seem to be much of an issue either - even if i bump that up to the double or reduce it by half, results are still almost the same. neither does the video engine (qt/viddl) or using jit.qt.grab instead of dx.grab do anything. apart, cpu/gpu/mem/etc. usage is pretty low, eg. cpu ranging about 20%.

again, thanks so much for any help!!!
karl


short update: i think i found the culprit.

the camera does deliver 150fps but only when running in Y8 colormode (which is pretty much raw, undebayered data), not when set to yuv422 (= uyvy) or rgb. i'm not sure wether the problem is jit.dx.grab not supporting that or wether this should be offered as "format" by the driver - i had an imaging source camera once and i think there this mode popped up in the formatlist... but i'll further investigate and report.

short update: i think i found the culprit.
the camera does deliver 150fps but only when running in Y8 colormode (which is pretty much raw, undebayered data), not when set to yuv422 (= uyvy) or rgb. i'm not sure wether the problem is jit.dx.grab not supporting that or wether this should be offered as "format" by the driver - i had an imaging source camera once and i think there this mode popped up in the formatlist... but i'll further investigate and report.
best!
k


Hi Karl, can you comment on the degree of latency you saw on your Chameleon3 setup in Max? I'm looking for a really fast responding system, and am considering the Chameleon3 camera because of the high frame rates. In the following thread SDI is mentioned as perhaps better than USB 3 for low latency, so I'm really interested in your experience.

https://cycling74.com/forums/low-latency-video-input-seemingly-impossible

Hi Karl, can you comment on the degree of latency you saw on your Chameleon3 setup in Max? I'm looking for a really fast responding system, and am considering the Chameleon3 camera because of the high frame rates. In the following thread SDI is mentioned as perhaps better than USB 3 for low latency, so I'm really interested in your experience. 

https://cycling74.com/forums/low-latency-video-input-seemingly-impossible 

150fps with ptgrey chameleon 3 camera?