i'll be making binary releases as well for those without Visual Studio
I was plannning on putting the binaries on the GitHub download page, but I guess Contributions may be a sensible place to put it
i think the AddonPack is a bit of a failed concept. It works for some users but I personally hate the idea of dumping all available addons into my vvvv folder. i never use it except sometimes to get Box2D :(
i do have my own ideas as to how i think plugins should be distributed, but i think i need to make a demo rather than talk about it since last time there wasn't much enthusiasm
I understood what you're talking about..
.. now VVVV takes almost one minute to load for me...
... But It's ok because I'm just learning and I want all the nodes available while playing...
When It will be time for a setup or an installation, I think I'll clean all the contribution and leave just those that I'm using.
Btw, Elliot, thanks for your awesome work you're doing..
Kinect and EmguCV stuff are astonishing
really nice stuff , do you think it will be possible to get all that stuff working in dynamic plugin editor?
Also i had the chance testing the plugin , but just using emgu videoin i get a lower frame rate than normal video in node almost half the frame rate , is that normal? or do you experience the same problem?
see the screenshot of the patch a few up
there's an example of a dynamic plugin template for Image filters
Are you using the binaries from a while back or a recent version?
EmguCV uses video for windows to grab the frames which is a little slow
but the capture mechanism can of course change (i think it's worth writing / fairly trivial to make a DirectShow based VideoIn node that outputs CVImageLink)
Of course, it's also very possible to make things like Point Grey SDK VideoIn nodes or CLEye for more direct camera access.
"i think the AddonPack is a bit of a failed concept".
Mm wouldn't go that far ;) it's really useful for a dev environment perspective, where you need as many tools as you need (most used bits for me are hittest/2d meshes/some texturefx/box2d).
For production it's of course not ideal indeed, since only want what i need (my opinion of course, some improvements always welcome, but i think bit of balance would make sense)
But having to go in contrib grab this specific plugin on every new beta would feel much more of a pain ;)
(back to cv stuff) ;)
Try using HS instead of LK, much less noisy (LK is good for sparse, not that great for dense, as you can see in the picture). And grayscale bit on it's own node, so you only do once (most filters need that so doing multiple time is a waste of precious cpu cycles ;)
ideally if the greyscale conversion is already performed, then other nodes should automatically share that cached version
i.e. there's a register of conversions for each CVImageLink, so if 2 nodes ask for the same type which is non native to the output, then the conversion will only happen once and they share the object with ReadWriteLock architecture
this is the direction i'm going in
there needs to be more communication up/downstream than there is at the moment
but other issues to cook with for the time being
And thanks for the Hs tip! i was trying to find comparison images,
i'll put an emum input on (i always forget how easy it is to do that with V2 of plugininterfaces
Skadoosh
Wow
I mentioned it.. maybe two month ago..
You've a lot of memory
:D
Will this be a contribution?
Tnx Elliot exSugoku..
it's already on GitHub
https://github.com/elliotwoods/VVVV.Nodes.EmguCV
i'll be making binary releases as well for those without Visual Studio
I was plannning on putting the binaries on the GitHub download page, but I guess Contributions may be a sensible place to put it
i think the AddonPack is a bit of a failed concept. It works for some users but I personally hate the idea of dumping all available addons into my vvvv folder. i never use it except sometimes to get Box2D :(
i do have my own ideas as to how i think plugins should be distributed, but i think i need to make a demo rather than talk about it since last time there wasn't much enthusiasm
I understood what you're talking about..
.. now VVVV takes almost one minute to load for me...
... But It's ok because I'm just learning and I want all the nodes available while playing...
When It will be time for a setup or an installation, I think I'll clean all the contribution and leave just those that I'm using.
Btw, Elliot, thanks for your awesome work you're doing..
Kinect and EmguCV stuff are astonishing
really nice stuff , do you think it will be possible to get all that stuff working in dynamic plugin editor?
Also i had the chance testing the plugin , but just using emgu videoin i get a lower frame rate than normal video in node almost half the frame rate , is that normal? or do you experience the same problem?
see the screenshot of the patch a few up
there's an example of a dynamic plugin template for Image filters
Are you using the binaries from a while back or a recent version?
EmguCV uses video for windows to grab the frames which is a little slow
but the capture mechanism can of course change (i think it's worth writing / fairly trivial to make a DirectShow based VideoIn node that outputs CVImageLink)
Of course, it's also very possible to make things like Point Grey SDK VideoIn nodes or CLEye for more direct camera access.
What camera are you using?
elliot
"i think the AddonPack is a bit of a failed concept".
Mm wouldn't go that far ;) it's really useful for a dev environment perspective, where you need as many tools as you need (most used bits for me are hittest/2d meshes/some texturefx/box2d).
For production it's of course not ideal indeed, since only want what i need (my opinion of course, some improvements always welcome, but i think bit of balance would make sense)
But having to go in contrib grab this specific plugin on every new beta would feel much more of a pain ;)
(back to cv stuff) ;)
Try using HS instead of LK, much less noisy (LK is good for sparse, not that great for dense, as you can see in the picture). And grayscale bit on it's own node, so you only do once (most filters need that so doing multiple time is a waste of precious cpu cycles ;)
@flateric - heya!
the model i'm going for is fewest nodes possible
ideally if the greyscale conversion is already performed, then other nodes should automatically share that cached version
i.e. there's a register of conversions for each CVImageLink, so if 2 nodes ask for the same type which is non native to the output, then the conversion will only happen once and they share the object with ReadWriteLock architecture
this is the direction i'm going in
there needs to be more communication up/downstream than there is at the moment
but other issues to cook with for the time being
And thanks for the Hs tip! i was trying to find comparison images,
i'll put an emum input on (i always forget how easy it is to do that with V2 of plugininterfaces