Hello,
i finally have an evaluation licence for the HALCON lib, for 1 month.
i compile the halcon plug-in like explain in the readme. compilation was no problem. in Gem/src, i did a : ln -s plugins/*/.libs/*.so .
so i've got 5 gem_video plug in : DC1394, DV4L, HALCON, V4L, V4L2
when i create a pix_video device i have this in pd log :
[pix_video]: backend #0='v4l2' : v4l2 analog [pix_video]: backend #1='v4l' : v4l analog [pix_video]: backend #2='dc1394' : dc1394 iidc
in the terminal : dylib loading file '/home/nusmuk/pd/Gem/src/gem_videoDC1394.so'! dylib loading file '/home/nusmuk/pd/Gem/src/gem_videoDV4L.so'! dylib loading file '/home/nusmuk/pd/Gem/src/gem_videoHALCON.so'! library loading returned: dlerror 'libhalconcpp.so: cannot open shared object file: No such file or directory' dylib loading file '/home/nusmuk/pd/Gem/src/gem_videoV4L.so'! dylib loading file '/home/nusmuk/pd/Gem/src/gem_videoV4L2.so'!
so, why did DV4L is not listed? is DC1394 replacing it?
i try to cp libhalconcpp.so in diferents place, but i still have the same error. what sould i do so that gem_videoHALCON.so can load libhalconcpp.so?
thanks Cyrille
On 2010-09-30 13:17, cyrille henry wrote:
Hello,
i finally have an evaluation licence for the HALCON lib, for 1 month.
cool.
i compile the halcon plug-in like explain in the readme. compilation was no problem. in Gem/src, i did a : ln -s plugins/*/.libs/*.so .
so i've got 5 gem_video plug in : DC1394, DV4L, HALCON, V4L, V4L2
not necessarily. you have compiled 5 plugins, but some of them might not have enabled their code. e.g. if configure cannot find libdv, then you will end up with a bare gem_videoDV4L.so, that basically does nothing.... anyhow
so, why did DV4L is not listed?
see above.
is DC1394 replacing it?
no, dc1394 uses idc (industrial video over ieee1394), wherase dv4l uses IEC 61834 (aka: consumer a/v over ieee1394)
i try to cp libhalconcpp.so in diferents place, but i still have the same error. what sould i do so that gem_videoHALCON.so can load libhalconcpp.so?
did you follow the steps in plugins/videoHALCON/README.txt that say: <snip> probably this won't work, with Gem complaining that it cannot find "libhalconcpp.so" or similar. in this case should tell the linker where to find the halcon-libraries, using the LD_LIBRARY_PATH variable: $ LD_LIBRARY_PATH=${HALCONROOT}/lib/${HALCONARCH} pd -lib Gem should do the trick. </snip>
mfgasdr IOhannes
ok, thanks for all the answer. i'm sorry, i was so exited to have it compiled, that i miss the end of the readme.
so, i'll not ask how to open a camera, since i now have read it till the end!
sending : device GigEVision::0030530f8e64 did not work, but : device GigEVision:default:0030530f8e64 did work.
so, i now have an image. well, i would be better if i had a lens on this camera ;-)
anyway, i noticed that some images are not correct. in attachment, you can find 2 examples of bad images...
Cyrille
Le 30/09/2010 13:55, IOhannes m zmoelnig a écrit :
On 2010-09-30 13:17, cyrille henry wrote:
Hello,
i finally have an evaluation licence for the HALCON lib, for 1 month.
cool.
i compile the halcon plug-in like explain in the readme. compilation was no problem. in Gem/src, i did a : ln -s plugins/*/.libs/*.so .
so i've got 5 gem_video plug in : DC1394, DV4L, HALCON, V4L, V4L2
not necessarily. you have compiled 5 plugins, but some of them might not have enabled their code. e.g. if configure cannot find libdv, then you will end up with a bare gem_videoDV4L.so, that basically does nothing.... anyhow
so, why did DV4L is not listed?
see above.
is DC1394 replacing it?
no, dc1394 uses idc (industrial video over ieee1394), wherase dv4l uses IEC 61834 (aka: consumer a/v over ieee1394)
i try to cp libhalconcpp.so in diferents place, but i still have the same error. what sould i do so that gem_videoHALCON.so can load libhalconcpp.so?
did you follow the steps in plugins/videoHALCON/README.txt that say:
<snip> probably this won't work, with Gem complaining that it cannot find "libhalconcpp.so" or similar. in this case should tell the linker where to find the halcon-libraries, using the LD_LIBRARY_PATH variable: $ LD_LIBRARY_PATH=${HALCONROOT}/lib/${HALCONARCH} pd -lib Gem should do the trick. </snip>
mfgasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Very nice ! ;) I hope it will work perfectly soon. ++
Jack
Le jeudi 30 septembre 2010 à 15:10 +0200, cyrille henry a écrit :
ok, thanks for all the answer. i'm sorry, i was so exited to have it compiled, that i miss the end of the readme.
so, i'll not ask how to open a camera, since i now have read it till the end!
sending : device GigEVision::0030530f8e64 did not work, but : device GigEVision:default:0030530f8e64 did work.
so, i now have an image. well, i would be better if i had a lens on this camera ;-)
anyway, i noticed that some images are not correct. in attachment, you can find 2 examples of bad images...
Cyrille
Le 30/09/2010 13:55, IOhannes m zmoelnig a écrit :
On 2010-09-30 13:17, cyrille henry wrote:
Hello,
i finally have an evaluation licence for the HALCON lib, for 1 month.
cool.
i compile the halcon plug-in like explain in the readme. compilation was no problem. in Gem/src, i did a : ln -s plugins/*/.libs/*.so .
so i've got 5 gem_video plug in : DC1394, DV4L, HALCON, V4L, V4L2
not necessarily. you have compiled 5 plugins, but some of them might not have enabled their code. e.g. if configure cannot find libdv, then you will end up with a bare gem_videoDV4L.so, that basically does nothing.... anyhow
so, why did DV4L is not listed?
see above.
is DC1394 replacing it?
no, dc1394 uses idc (industrial video over ieee1394), wherase dv4l uses IEC 61834 (aka: consumer a/v over ieee1394)
i try to cp libhalconcpp.so in diferents place, but i still have the same error. what sould i do so that gem_videoHALCON.so can load libhalconcpp.so?
did you follow the steps in plugins/videoHALCON/README.txt that say:
<snip> probably this won't work, with Gem complaining that it cannot find "libhalconcpp.so" or similar. in this case should tell the linker where to find the halcon-libraries, using the LD_LIBRARY_PATH variable: $ LD_LIBRARY_PATH=${HALCONROOT}/lib/${HALCONARCH} pd -lib Gem should do the trick. </snip>
mfgasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 2010-09-30 15:10, cyrille henry wrote:
ok, thanks for all the answer. i'm sorry, i was so exited to have it compiled, that i miss the end of the readme.
so, i'll not ask how to open a camera, since i now have read it till the end!
sending : device GigEVision::0030530f8e64 did not work, but : device GigEVision:default:0030530f8e64 did work.
so, i now have an image. well, i would be better if i had a lens on this camera ;-)
anyway, i noticed that some images are not correct. in attachment, you can find 2 examples of bad images...
hmm, no that i have this camera, this get's even stranger... i cannot reproduce the bad images, however: - it's only b/w (well, i guess that's the cam) - framerate is pretty bad (afaict, its about 10fps :-(, but that might be related to something else) - latency is worse than expected (see attached feedback image)
however, all images captured are fine.
note however, that i experimented a little bit with the pylon SDK before trying with HALCON. maybe this put the cam into a more appropriate mode...
(eventually i'll write an pylon backend, it seems to be available without having to pay a license, though it's somehow hard to get your hands on as well)
fgamsdr IOhannes
Le 12/10/2010 15:20, IOhannes m zmoelnig a écrit :
On 2010-09-30 15:10, cyrille henry wrote:
ok, thanks for all the answer. i'm sorry, i was so exited to have it compiled, that i miss the end of the readme.
so, i'll not ask how to open a camera, since i now have read it till the end!
sending : device GigEVision::0030530f8e64 did not work, but : device GigEVision:default:0030530f8e64 did work.
so, i now have an image. well, i would be better if i had a lens on this camera ;-)
anyway, i noticed that some images are not correct. in attachment, you can find 2 examples of bad images...
hmm, no that i have this camera, this get's even stranger... i cannot reproduce the bad images, however:
- it's only b/w (well, i guess that's the cam)
yes, i think this cam is B/W
- framerate is pretty bad (afaict, its about 10fps :-(, but that might
be related to something else)
outch! it's a 120fps cam...
- latency is worse than expected (see attached feedback image)
yes, this is not really usable...
however, all images captured are fine.
ok, strange.
note however, that i experimented a little bit with the pylon SDK before trying with HALCON. maybe this put the cam into a more appropriate mode...
(eventually i'll write an pylon backend, it seems to be available without having to pay a license, though it's somehow hard to get your hands on as well)
cool
thanks Cyrille
fgamsdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 2010-10-14 10:51, cyrille henry wrote:
- it's only b/w (well, i guess that's the cam)
yes, i think this cam is B/W
yep.
- framerate is pretty bad (afaict, its about 10fps :-(, but that might
be related to something else)
outch! it's a 120fps cam...
ok, think i have found some problems in my code. if i switch to asynchronous capturing, then i get way better framerates (e.g. 100fps and more; no easy way to really measure this)
- latency is worse than expected (see attached feedback image)
yes, this is not really usable...
ok, with asynchronous capturing this seems to get better as well. (see attached feedback image)
however, all images captured are fine.
ok, strange.
ok, so i discovered that i _sometimes_ get dropouts as well. i seem to remember, that i even got the dropouts with halcon's HDevelop tool, which i consider the reference implementation. this would indicate that the problems are either with the API itself (which i somehow doubt), or with the networking configuration (jumbo frames or the like)
i'll investigate.
fgmasdr IOhannes
hello,
[...]
ok, think i have found some problems in my code. if i switch to asynchronous capturing, then i get way better framerates (e.g. 100fps and more; no easy way to really measure this)
cool!
- latency is worse than expected (see attached feedback image)
yes, this is not really usable...
ok, with asynchronous capturing this seems to get better as well. (see attached feedback image)
what is Gem framerate, your screen framerate, and do you use sync to vblank? all of this can increase latency of the screen side...
ok, so i discovered that i _sometimes_ get dropouts as well. i seem to remember, that i even got the dropouts with halcon's HDevelop tool, which i consider the reference implementation. this would indicate that the problems are either with the API itself (which i somehow doubt), or with the networking configuration (jumbo frames or the like)
i think the manufacturer recommendation is to use only an intel ethernet card!
Cyrille
i'll investigate.
fgmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 2010-10-14 12:24, cyrille henry wrote:
hello,
what is Gem framerate, your screen framerate, and do you use sync to vblank? all of this can increase latency of the screen side...
yes of course. obviously for a feedback image you won't get better than the lowest framerate. so here's some more information: - sync to vblank is turned off - Gem's framerate is 100fps - display is a Samsung SyncMaster DFP 1280x1024@60.02Hz
timing image attached a last time (cannot resist)
i changed the network settings to use jumbo frames: # ifconfig eth1 mtu 9000
the networking card i use is (i think): "Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Ctrl."
i haven't seen any problems with the images since. (though just before it was basically 2/3 white stripes)
cyrille, did you ever try jumbo frames?
fgmadr IOhannes
-
cyrille henry -
IOhannes m zmoelnig -
Jack