Capture software for Linux

[JamesF]

Well, the lack of support for stuff I wanted finally got to me and over the last week or three I've been pounding the keyboard writing a new capture application for Linux.  There are quite a few reasons why I wanted to do this, but the main ones are that I wanted something Linux-based because that's what I'm used to and because it means I can use the software on ARM-based systems, because I wanted to be able to do things such as run capture applications from a command line, because I wanted to be able to run them unattended and remotely over long periods of time, because nothing really had all the functionality I want or only supported a limited range of cameras and because I want to be able to chain together strings of applications to process data automagically.

My intention is to have a camera control library written in C that provides an API for controlling Video4Linux 2 based cameras, the ZW ASI cameras and the QHY cameras for a start.  I also have a Firefly MV so I'll try to get that to work as well, though I may end up having to write my own libusb-based interface for that to sit below my API.

Because it's in C the library should be usable from any number of other programming languages depending on what I need at the time.

As I wrote at the start, my first effort has been yet another capture program.  It's far from finished, but I'm making reasonably rapid progress now.  The program is written in C++ (which I learnt over 25 years ago and haven't used a great deal since) and is based on the Qt toolkit (that I've never used before) which in theory makes it portable to Windows, Macs and some mobile devices, but as I have no experience of programming on Macs and little on Windows I'd not like to bet on  that.  To add to the complexity it's also a threaded application, and I've not worked with threads before either  The UI borrows ideas from FireCapture because I get on quite well with that and because I know I'm rubbish at UI design.

Anyhow, for the first time tonight having bashed out a fair few thousand lines of code it's celebration time because I managed to get an image to display on the screen for the first time:

This is with one of my SPC900 cameras, but it also works with my modded Lifecam (though that doesn't have a lens in any more, so I can't get an image out of that without putting it in a telescope).

There's still a fair way to go yet, but this is a major milestone, hence the posting

James

Edited September 25, 2013 by JamesF

[AlexB67]

Looks nice James. Seems we are in a similar boat, I started using Qt for my calculator app using Qt/C++.  Many moons ago I used C and never used C++ before in earnest, though often had to read code in it and code little bits, so was I somewhat familiar. Anyway after blowing away the cog webs all the coding came back rather easily and find Qt very nice to work with. 

I think you'll find the window port to be a breeze for the Qt bit anyway,  butdepending what other dependencies you've got on other libs who knows, Qt is not a 100% native desktop integration but works well enough in windows. Not tried a mac port myself, but if need be you got the nice Q_OS_LINUX and Q__OS_WIN AND Q_OS_MAC macros to get out of jail for some specifics if need be. also Qt has its own threads of course so I guess using them if possible to avoid more OS change troubles. I find it to work really well in windows, KDE, Gnome whatever you throw at it, though note some themes can be a bit buggy with GUI layouts spacing sometimes, invariably this is the window manager theme and font handling issue more than a Qt fault I found across various windows managers. You can always force you own theme also  on whatever platform it runs on with style-sheets so it will look the same on all platforms.

God luck with the fun

Edited September 26, 2013 by AlexB67

[AlexB67]

what linux dist are you using out of curiosity ? Looks like the old style KDE theme I recall from some years ago, always liked that one.

[NickK]

If you put in INDI support you could have SX and ATIK support too..

[JamesF]

what linux dist are you using out of curiosity ? Looks like the old style KDE theme I recall from some years ago, always liked that one.

I'm using Mint with the default theme.  It's possible that the default styling for Qt on Linux shares its roots with KDE though.

James

[JamesF]

Looks nice James. Seems we are in a similar boat, I started using Qt for my calculator app using Qt/C++.  Many moons ago I used C and never used C++ before in earnest, though often had to read code in it and code little bits, so was I somewhat familiar. Anyway after blowing away the cog webs all the coding came back rather easily and find Qt very nice to work with. 

I think you'll find the window port to be a breeze for the Qt bit anyway,  butdepending what other dependencies you've got on other libs who knows, Qt is not a 100% native desktop integration but works well enough in windows. Not tried a mac port myself, but if need be you got the nice Q_OS_LINUX and Q__OS_WIN AND Q_OS_MAC macros to get out of jail for some specifics if need be. also Qt has its own threads of course so I guess using them if possible to avoid more OS change troubles. I find it to work really well in windows, KDE, Gnome whatever you throw at it, though note some themes can be a bit buggy with GUI layouts spacing sometimes, invariably this is the window manager theme and font handling issue more than a Qt fault I found across various windows managers. You can always force you own theme also  on whatever platform it runs on with style-sheets so it will look the same on all platforms.

God luck with the fun

Thank you

I have to admit that the possibility of porting to the Mac or WIndows is just a bonus for me at the moment.  My primary goal is getting a set of tools I can use for capturing data on Linux.  For example having an all-sky camera that I could run off a Raspberry Pi or Sheevaplug, or something similar to record the position of the Sun at noon each day to create an Analemma image, but without needing to run a desktop or laptop full time to do so.

James

[JamesF]

If you put in INDI support you could have SX and ATIK support too..

Yes, I'm pondering over INDI.  I've been pondering a long time.  I think things are going to remain that way for a while yet

James

[DaveHKent]

Thanks for producing this. I'll bookmark this thread and give it a go.

I'm mainly a linux user and get frustrated at how slow the netbook I bought for astro stuff runs in windows, compared to linux. Windows is only there as most of the astro apps want to use it.

[JamesF]

Thanks for producing this. I'll bookmark this thread and give it a go.

I'm mainly a linux user and get frustrated at how slow the netbook I bought for astro stuff runs in windows, compared to linux. Windows is only there as most of the astro apps want to use it.

I shall keep the thread updated with my progress.

There's still a fair bit to do, but once I have the basic controls properly functional and have tested support for a few more cameras I'll look at putting together an alpha release because I think camera support is going to be the main stumbling block.  After that I can look at creating histograms and overlaying reticles etc.

James

[cgarry]

Good work sir!

I have been planning to move PIPP over to using the QT toolkit instead of C# for some time now.  I like the idea of being able to produce native versions for Linux, Windows and OS X.  Now I just need to find the time to actually do it...

Cheers,

Chris

[JamesF]

I have been planning to move PIPP over to using the QT toolkit instead of C# for some time now.  I like the idea of being able to produce native versions for Linux, Windows and OS X.  Now I just need to find the time to actually do it...

PIPP ought to be relatively easy I'd have thought, just quite a slog because there are so many controls.  As a newcomer to Qt the bit that took me longest was getting my head around all the layout stuff and how it is supposed to hang together.  That may well be at least partially due to the fact that I didn't use the QtDesigner IDE.  I've never really got on very well with IDEs.  Give me half a dozen terminal windows and vi any day

James

[JamesF]

Oh, irritatingly I've not managed to find an implementation of the Ut codec for Linux yet.  I've not looked that hard, but it would be handy if someone had already done it.

James

[mikehab]

Very interesting thread James - and congrats on the progress....looks promising.  I'll definitely be following this thread with keen interest.

I would be interested to hear why you've chosen to do this in C++ specifically.  I was a C/C++ programmer for 10 years and then a Java programmer for 10+ years (though never done anything with video capture specifically) ... and I would definitely choose Java over C++ any day purely for a) speed of development and portability ... so I'm just wondering why people tend write these vid capture apps in C# / C++ rather than Java.  Presumably at some point you have to access the camera-specific native drivers ... so maybe that's easier to access those low-level drivers directly via C++?

I definitely don't want to get into any kind of 'religious' C++ versus Java debate ... but if written in Java then it would obviously run on all platforms without the need to port/re-compile... and also be much easier to get an Android (SmartPhone) version too if written in Java.

Just wondering... ;-)

(Still very impressed with your progress though - congrats!)

[AstroTux]

Nice one James :icon_salut: .

I've just moved to Linux Mint 15 myself as I just can't get along with Ubuntu any more, but it seems I've hit a snag. The 3.80 kernel does not seem to play happily with the SPC900NC, although the device is recognised as such. wxAstroCapture and various others do not seem to be able to control it.

Is this something to do with V4L2, or the kernel driver for the SPC900? No matter how much I search there is very little information on t'inerweb about this.

Do you have any ideas on this, and is there anything I can do? I'm quite happy working with GTK+ and libusb, etc., in C. As you probably know I'm mainly a hardware guy but use C a lot for embedded devices - just not C++. Also if you need anyone to test your software please count me in.

It would be nice to see the SPC900 properly supported again. In order to control it my 'field' laptop still runs Ubutnu 10.04......... :grin:

Looking forward to the potential release of your software,

all the best,

Alan

[cgarry]

Oh, irritatingly I've not managed to find an implementation of the Ut codec for Linux yet.  I've not looked that hard, but it would be handy if someone had already done it.

James

Ut codec support should easy enough with FFmpeg, that is what I used.  I can give you the AVI/SER file generation code from PIPP if you like, save you reinventing the wheel completely.

Chris

[JamesF]

I would be interested to hear why you've chosen to do this in C++ specifically.  I was a C/C++ programmer for 10 years and then a Java programmer for 10+ years (though never done anything with video capture specifically) ... and I would definitely choose Java over C++ any day purely for a) speed of development and portability ... so I'm just wondering why people tend write these vid capture apps in C# / C++ rather than Java.  Presumably at some point you have to access the camera-specific native drivers ... so maybe that's easier to access those low-level drivers directly via C++?

I definitely don't want to get into any kind of 'religious' C++ versus Java debate ... but if written in Java then it would obviously run on all platforms without the need to port/re-compile... and also be much easier to get an Android (SmartPhone) version too if written in Java.

Well, the first obstacle is that I don't have time to learn Java as well

The camera API library talks to the device drivers (for the V4L2 support) and to the USB layer (via libusb).  I will at some point also have to get it to talk to the ASI interface library which is closed-source binaries and I'd also like to be able to call the libraries from whatever language I feel is appropriate at the time (in particular I use Perl for a lot of scripting work, but I may also want a web interface) and I want to be able to build small light-weight tools that I can chain together when required.  C suits those requirements well and so that is what I've used.

For this particular capture application I've always had Qt in mind for the UI and the fact that Qt5 has some nice integration with the video layer on the Raspberry Pi which apparently improves performance quite significantly is a bonus.  I am developing with Qt4.8 though as that's what's installed on my desktop and I can't be bothered to change it right now.  Using Qt dictates the use of C++ and as I have no objections to C++ I was happy to go that way.

I do admit to a minor concern that some people complain about the performance of FireCapture, which is written in Java, compared with other capture applications.  I've never noticed it myself, but at the moment I'm running Windows on an i3-based laptop with a load of RAM.  The situation when using a low-powered low-memory notebook may be quite different.

James

[AlexB67]

That may well be at least partially due to the fact that I didn't use the QtDesigner IDE.  I've never really got on very well with IDEs.  Give me half a dozen terminal windows and vi any day

James

I do not use Qt designer, but do use Qt Creator,   (but also a fan of vi  & emacs ). I do not use the form GUI designer part of it and write all my GUI components from the ground up, no dragging things on forms :0) Why, because that way I understand what I have written, especially when it comes to event processing with all the  GUI forms design, drag and drop stuff in Qt designer, I don't learn it properly.  Since I found out too, that once you get stuck with the GUI designers with Qt and it cannot do something, it becomes  a pain hacking around, interfering with auto generated code, it is just not quite as flexible.

I do like Qt Creator as a framework for Qt development because the syntax highlighting and some other constructs work well with it out of the box, though I make sure I also understand the build tree and it is quite flexible adding stuff, linking to other libs etc . At the end I'd probably have it so it does not  depend on Qt Creator, but that should be no big issue from what I can see, it is not like Visual studio in that sense depending on loads files part of the IDE ( i.e. a pain, something I do not like ) .  Qt Creator also works on all the platforms and porting the build tree using it's build in features are also not platform specific.  QT Creator has builds for windows, Mac, and Linux, Android and some other devices I never even bothered checking, ultimately I'll never be coding for the mobile anyway. I think Qt creator is the first IDE I ever used in earnest, mostly I was always a vi/emacs man, but I do think it is very easy to use.  But I do know  that in many cases the old habits of Unix people are ingrained, it is written in their genes to use vi

Edited September 26, 2013 by AlexB67

[JamesF]

Nice one James :icon_salut: .

I've just moved to Linux Mint 15 myself as I just can't get along with Ubuntu any more, but it seems I've hit a snag. The 3.80 kernel does not seem to play happily with the SPC900NC, although the device is recognised as such. wxAstroCapture and various others do not seem to be able to control it.

Is this something to do with V4L2, or the kernel driver for the SPC900? No matter how much I search there is very little information on t'inerweb about this.

Do you have any ideas on this, and is there anything I can do? I'm quite happy working with GTK+ and libusb, etc., in C. As you probably know I'm mainly a hardware guy but use C a lot for embedded devices - just not C++. Also if you need anyone to test your software please count me in.

It would be nice to see the SPC900 properly supported again. In order to control it my 'field' laptop still runs Ubutnu 10.04......... :grin:

I'm actually slightly confused myself

I'm running Mint 15 and was fully-expecting to have to ignore the fact that the SPC900 is advertised by V4L2 and write my own user-space driver on top of libusb.  I know the PWC driver in the kernel hasn't been maintained properly for some time and certainly didn't work with some kernels.  I was quite surprised therefore when it seemed to "just work" with the kernel in Mint 15.  I've not done incredibly extensive testing just yet however  I'm not aware that anyone has been working on the driver and the V4L2 layer has changed massively since the v2.8 and v3.0 kernels.  So much so in fact that I wasn't sure that my patches to the UVC driver to make it play nicely with the Xbox camera were still going to work.

I think wxastrocapture may use its own user-space driver.  If so perhaps that has broken with later kernels.  Without access to the source it's really hard to tell.

Have you tried running Cheese with the SPC900 to see if that works with the later kernel?  That might at least give some hope.  You'll be on my list of testers, anyhow

James

[JamesF]

Ut codec support should easy enough with FFmpeg, that is what I used.  I can give you the AVI/SER file generation code from PIPP if you like, save you reinventing the wheel completely.

Thank you, Chris.  When I get that far I may well be knocking on your door to talk about it  I also want to look into what's possible with just wrapping up the video stream direct from the camera with the V4L2 devices.  I'm fairly sure that doing that should be fairly straightforward and makes the program at least usable.

My next step however is to get things working so changing the controls is properly synchronised between the main UI thread and the thread managing the camera.  I think I have the mutexes all set up correctly, but it's a bit hairy and made even more so by some cameras that only seem to want to set some controls after others.

James

[JamesF]

I do know  that in many cases the old habits of Unix people are ingrained, it is written in their genes to use vi

Guilty as charged, I'm afraid

I did actually start out on UNIX using something other than vi, but I can't recall what it was off the top of my head.  Then I got into uEmacs, but when I left university I was working on a large range of different UNIX boxes and vi was the only editor guaranteed to be present on all of them so that's what I used and I have done so for the last 25 years.  Now vim does useful stuff such as syntax highlighting I've not seen a compelling reason to change

I don't know how much of a following Emacs still has.  I did know people at university (this was back in the days of 80x25 terminals, before most people had access to a machine with a GUI) who had emacs set as their login shell.

James

[Paul81]

Hi James, 

Your app is looking good! I am writing a live stacking imaging app myself (for Sx Lodestar cameras - see the Video Astronomy section - Lodestar Live), and also use QT (superb SDK). We definitely need more Linux and Mac stuff for astro (my app is for Mac, Linux and Windows). QT does make things nice and easy for cross platform, I find well written code ports first time.

Out of interest, have you got your app working with ZW ASI cameras? I am interested in getting one, but I need to capture on a platform other than Windows. I was curious to see if ZW release documentation on the USB protocol (which is why I mainly chose SX for my app).

[JamesF]

Hi James, 

Your app is looking good! I am writing a live stacking imaging app myself (for Sx Lodestar cameras - see the Video Astronomy section - Lodestar Live), and also use QT (superb SDK). We definitely need more Linux and Mac stuff for astro (my app is for Mac, Linux and Windows). QT does make things nice and easy for cross platform, I find well written code ports first time.

Out of interest, have you got your app working with ZW ASI cameras? I am interested in getting one, but I need to capture on a platform other than Windows. I was curious to see if ZW release documentation on the USB protocol (which is why I mainly chose SX for my app).

I have an ASI120 and intend that to be the next camera I get working.  ZW do provide a Linux library for their cameras, but it's binary-only.  It seems that few suppliers are quite as enlightened as Starlight Express  Using their library however looks like it means support for a range of their cameras (at least the 130MM, 120MC and 120MM) should be possible in one hit.  I'm not averse to a bit of reverse engineering, but neither am I averse to taking the most straightforward path if it means something becomes usable sooner

James

[StuW]

I've been playing with the ASI linux SDK James and it's not the easiest to use.  I've not managed to get it to read an image into QT yet as it seems tightly bound to OpenCV (i'm not a linux programmer so it could just be me!)

[JamesF]

Your app is looking good! I am writing a live stacking imaging app myself (for Sx Lodestar cameras - see the Video Astronomy section - Lodestar Live), and also use QT (superb SDK). We definitely need more Linux and Mac stuff for astro (my app is for Mac, Linux and Windows). QT does make things nice and easy for cross platform, I find well written code ports first time.

Just had a look at this, btw.  Looks very good.  I don't do any video astronomy, but I can understand the desire for it and had it in the back of my head to do something similar using the code I've written with the intention that the front end would be completely camera-agnostic.  I have quite a few other fish to fry first however

James

[JamesF]

I've been playing with the ASI linux SDK James and it's not the easiest to use.  I've not managed to get it to read an image into QT yet as it seems tightly bound to OpenCV (i'm not a linux programmer so it could just be me!)

Yes, I had a poke about in the internals of the Windows one when it was released and came to the conclusion that it's built around OpenCV.  I'm struggling to believe that the interfaces for these cameras can be at all complex in reality.  There's not exactly a whole pile of stuff to do.  I think some/many of them might even be simpler than a webcam as they don't continuously stream data.

The QHY cameras look a bit weird in some respects though.  By the looks of things they announce themselves from cold with a specific USB vendor-id and product-id and the driver downloads a new firmware image to them.  That done they warm reset and rejoin the USB bus with a different set of ids.

James