I'm writting a hobby project to deal with files on cameras.
Previously I found issues with the camera and the FolderBrowserDialog.
What I believe is happing is that the camera is using MTP or PTP (Picture Transfer Protocol not peer-to-peer).
In order to make interfacing with the camera more seamless I'd like to use PTP or MTP to access the camera. Are there any MTP / PTP Wrappers for .Net people can recommend? I'm keen to avoid writing my own or dabbling in unmanaged code if possible.
I have found this blog post by dimeby8 which has been a great starting point with a lot of useful information about how the protocol works, however it leaves a lot to be desired in the way of managed implementations
http://blogs.msdn.com/dimeby8/archive/tags/C_2300_/default.aspx
I have also found a crude C++/CLI MTP wrapper- it has next to no functionality but is a good demonstration of mixed managed/unmanged code:
http://ko.sourceforge.jp/projects/sfnet_mtpsharp/
And there's a CodePlex project but it doesn't demonstrate transfers or - what I'm interested in- editing camera metadata (specifically the camera date)
http://www.codeplex.com/portabledevicelib/
Have you had any success with this project?
Related
I am making a C# app to capture graphic from an avermedia pcie capture card.
But it seems that there are no out of box tools to do so.
So I made a C++ directshow app to do the capture, which is a console app and opens a capture window when running.
How can I redirect the output to a C# app? for example, to a CaptureElement?
So you want to have XAML CaptureElement connected to AverMedia PCIe capture card. This sounds like a well-understood challenge overall, however every other piece of technology you mentioned is eventually a bad choice: DirectShow, multiple apps with piping, redirection and fitting of cutsom code to XAML CaptureElement control.
Microsoft has intentionally been limited ways you can integrate different APIs and so there are not so many ways to get everything together.
Let us go over the supposed integration path. The capture card is supposed to be shipped with a compatible driver:
Video capture devices are supported through the UVC class driver and must be compatible with UVC 1.1
When this is the case, such devices are visible to Media Foundation API handling video capture among tasks. XAML CaptureElement would be able to see a video capture device through this API and this way everything is supposed to work without need to fit anything from your end.
If this is not happening, it suggests you are dealing with an unsupported device coming without suitable or compatible driver.
Previous media API in Windows was DirectShow but its days are gone. It remains perfectly working as a legacy framework, a lot of applications out there are still relying on it. Specifically it will not integrate with new technology like XAML and UWP. More to that, even Media Foundation itself, the current media API, in its public offering is lagging behind when it comes to fitting with most recent technology. Having said that it is a good idea to stay well clear of DirectShow here if this is at all possible.
I see no need for cross-process design with video travelling between process through piping. There is no good reason for such design and even though this can work efficiently (Windows itself proves it can work great in terms of performance by having so called Frame Server service in it), this is not to be built on piping. In your case it is unlikely to be have to be built on multiple processes either. Instead you can develop a native code DLL project that takes care of video acquisition and connects to managed code via suitable glue layer: C++/CLI, COM, C++/WinRT and such.
Then next thing is fitting to XAML CaptureElement. The control is designed to work with Windows.Media.Capture.MediaCapture class that talks to hardware and you don't have suitable hardware as you plan to implement your own acquisition layer. Long story short you are not supposed to forward external data to CaptureElement and you would have hard time doing this. Your best strategy is to upload externally obtained data to Windows.Graphics.Imaging.SoftwareBitmap or alike and take involved performance impact as acceptable. That is, you will be dealing with video frames as images.
An alternative way is to upload acquired video frames into Direct 3D 11 textures and it would open you a more performant way of integration with video related controls, such as Windows.UI.Xaml.Controls.SwapChainPanel however it would also require that you put much more development effort in there.
I recently came across libcinder which seems to be promising for creative coding.
It's for c++ but I'm more familiar with c#. Is there a way to use libcinder with c#?
Or maybe in c# world, there is some other collection of libraries / framework for the same purpose?
The first thing I'd like to try is to open an image then draw lines/rectangles on it, the second thing in my list is to open a live video and then draw some thing on the video. Is it the best choice to use cinder or should I just use OpenCV with c++/c#?
What libcinder feature are you looking for in "C# World". Many of the features listed on that link are already available in C# (.NET) since 2005-2008.
Example things that C#/.NET can do (same as libcinder):
Standalone Apps
Internet I/O
Platform Specific API's (PInvoke)
Xml & JSON Parsers
Full I/O Stuff
UI Events
Multi Touch
Communication API's
3D & 2D Graphics
Multimedia
In the newest Linux kernel, it supports Kinect through a driver. I want access to the RGB and D (depth) streams and put them into a 2D array, either 64bit ints, or two separate arrays will work. C# is preferred, C++ is acceptable.
So my question is: where can I find more information about this, e.g., articles and documentation? What would a simple example program look like, e.g., printing the color and depth at position 100x100?
I'll up-vote any good links, and accept the first working code sample.
Thanks,
Frankie
P.s., I'm aware of the OpenKinect, NITE, Microsoft SDK, etc., projects. I want this to be easy for me to install on other computers and Linux distros which is why the common kernel driver is preferred. My main use will be a web-cam that replaces pixels further away than depth X and saves to disk.
Update
Since asking I haven't gotten much further. I found this article. I checked out the Git repo, which doesn't seem to have been updated since April and I don't see any connection to the Linux Kernel or it ever being incorporated. There's no mention of Kinect in any later blog posts there, other than this unrelated one.
Update 2
I can't seem to find who applied the Kinect driver to the kernel. There is a mirror of the kernel on GitHub. I tried using Google to search it, but this query and variations didn't turn up anything. Then I tried searching GitHub with no positive hits. Does anyone have any information?
Unfortunately, the driver doesn't support the depth stream, only an unprocessed image from the monochrome sensor. So it's not possible using only the kernel driver. See also a blog post I wrote on this subject. If you remove the built-in kernel modules, you can do it with libfreenect though.
You can find the driver file here on GitHub: kinect.c.
The driver doesn't support a D stream according to the link you posted:
[media] gspca - kinect: New subdriver for Microsoft Kinect
The Kinect sensor is a device used by Microsoft for its Kinect
project, which is a system for controller-less Human-Computer
interaction targeted for Xbox 360.
In the Kinect device, RGBD data is captured from two distinct sensors:
a regular RGB sensor and a monochrome sensor which, with the aid of a
IR structured light, captures what is finally exposed as a depth map;
so what we have is basically a Structured-light 3D scanner.
The Kinect gspca subdriver just supports the video stream for now,
exposing the output from the RGB sensor or the unprocessed output from
the monochrome sensor; it does not deal with the processed depth
stream yet, but it allows using the sensor as a Webcam or as an IR
camera (an external source of IR light might be needed for this use).
The low level implementation is based on code from the OpenKinect
project (http://openkinect.org).
From source of the driver it appeares the author is Antonio Ospite reachable at ospite#studenti.unina.it
As already suggested by the comments the author should be able to answer all questions you asked since what you want is really dependent on what is exactly exposed by the driver (which might even be version dependent).
I'm trying to use a 2D camera to recognize the device/object a user is pointing at so I was looking for a skeleton tracking software using a 2D camera in order to be able to do that. Is there any open source project that deals with skeleton tracking using 2D cameras?
(I've gone through tons of links on Google and it seems like most of what's there is just research papers but no actual open source projects)
Thanks!
Skamleton could be an option. It's an open-source project in early stages, but it implements a background subtractor, a skin color classifier, blob tracking and face classification. There is a demo on YouTube.
Note Skamleton use simple cameras, not RGB-D (depth) cameras as the Kinectic system (Kinect uses a structured light device from PrimSense).
It seems there's kind of a pre-release of a SDK for Kinect from Microsoft. Perhaps this might be helpful for you:
http://nuigroup.com/forums/viewthread/11249/
(Although I think this won't be Open Source. But since you are using c#, a Microsoft SDK might be ok for you.)
This seems like an old post, but in case anyone is still looking Extreme Reality uses a regular webcam and does skeleton tracking. It's not open source, but I've played around with it a bit and it does seem to be fairly robust.
http://www.xtr3d.com/developers/resources/
I am working for a company where we are developing video chat support on an existing application. I have looked at various solutions for this like
Using Managed Direct show for video capture and streaming in C#
Some code samples in code project where we take an image and pass it over the network (I would call it rather a crude solution as this would eat up lot of bandwidth.
Code a compression algorithm from scratch from scratch and use it to compress-decompress video.
Now the challenge is that we are looking to achieve very high quality video streaming and the container application is coded in C#.NET
This is what I have proposed so far. The network logic to stream data is written in C# , the video compression to be written in VC++ and call this VC++ dll using pinvoke or either CLI which way possible.
I am looking for some one more experienced that me in this field who can suggest me if Iam going correct or can this be still improved.
The ultimate goal is high quality video streaming.
The codec can be any anything like h.2633, h.264 etc.
I've used several ways to get video streaming/conferencing with .net easily, without need to dig into directshow. (ok, dig some, but not deep :)
1) Use of plain Windows Media Encoder components. It is documented with samples in Windows Media Encoder SDK. Good for any high resolution streaming, but delay is too big for realtime chat (0.5-2 seconds at best). Modern Express Encoder SDK another option.
2) Microsoft Research ConferenceXP http://cct.cs.washington.edu/ Full featured conferencing API including application streaming. They too low level Windows Media coded filters and wrapped them into managed code. Works well. Easily customizable. Looks bit abandoned now.
3) Microsoft RTC Client up to version 1.3 - core of windows messenger.
pros: managed samples from Microsoft, good docs, reliable performance, freely redistributable, microsoft compatible (good) SIP stack included. Major conferencing vendors like Emblaze VCON based their solutions on it in some near past, not sure about this days, but I know that Tandberg licensed Microsft's VC-1.
cons: version up to 1.3 support h261-h263 video only. modern version with support of VC-1(h264) codec does not allow direct serverless ip-ip connections. It does at require Microsoft Live Communications server. Newer version SDK does not cover well video conferencing calls.
http://msdn.microsoft.com/en-us/library/ms775892(VS.85).aspx
Please let us know what platform you have chosen. By the way, I've even used ConferenceXP video rtp part with RTC 1.3 voice/SIP features together to improve video quality, so you have wide choice of managed technologies here. Another thing is Live Meeting at which I had no chance to take good look yet.
Save yourself the trouble and use VLC. There are some decent .NET wrappers for it (http://forum.videolan.org/viewtopic.php?f=32&t=52021&start=30)
We are using C# and VLC for an IPTV network. We take input off DISH network satellites via Osprey-450 video capture devices on a Windows XP server. From there, we have a .NET server component that we wrote in C# that uses VLC behind the scenes (starting separate processes in .NET to control the vlc.exe instances). The VLC processes transcode and stream the signals over a network (.h264 or MPEG-4, we've successfully done both).
On the client side we have a C# WinForm application that uses an embedded VLC Viewer to view multicast signals. This application is mainly for command & control. The real use of the multicast signals happens when our set top boxes attached to our TV's decode and display the streams.
We thought we were going to have to write our own DirectX encoders too, but don't go to all the trouble. VLC works really well and has enough C# support to be very useful. Feel free to e-mail me if you have specific questions about implementation.
You should check out the Ucentrik SDK. This SDK will enable you to integrate rich-media functionality such as video, audio, chat, remote-desktop sharing and control and video recording in your applications. The video codecs supported are VP8 (Google), Theora, and x.264. Additionally, the rich media traffic is encapsulated within an HTTP protocol to enable it to traverse firewalls that enable normal web traffic. This technology is completely free and you can download the SDK and request an API key so that you can evaluate without investing any time on setting up the infrastructure. In the next few months, we are releasing a server component so that you can download and host the infrastructure your self or your customer. The technology supports 1-to-many connections which means that you can create video conferences if you like. The features are highly modular so that you can integrate just the video or audio or desktop share or a combination of the technologies using the same SDK... You should request for an SDK available here: www.ucentrik.com. Additionally, there are some video's here: http://www.youtube.com/user/ucentrik
good luck.
Ucentrik has just released an open-source call-center application that integrates the CTX technology. This call-center application implements the video, audio, desktop/application sharing (with control), text chat functionality available from the CTX API. The application also includes some business logic specifically around providing the ability to route the calls to an agent that is available or have specific skill-set. The project is available at http://vcca.codeplex.com - please note that you will require access to the Ucentrik CTX SDK which is available for request on the Ucentrik website (www.ucentrik.com). Good luck.