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

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

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

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

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

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

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

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

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

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

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

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

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

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

say, why do you convert the raw files to monochrome?

Because the Moon really is fairly monochrome.  If you do some fairly heavy processing you can drag a little colour out, but as I don't intend to do that the images might as well be monochrome.

James

Have you bought the LP clip filter?

I haven't.  I do have a 2" LP filter that I can fit to the filter threads on the end of the lens using step-down rings, but I only use that if I'm imaging very close to the horizon.

James

Oh dear... I wonder how you split up quotes to answer parts individually....... aarrgghh!

You can insert the quote tags manually and it appears to handle things properly.  It's a bit of a pain though

James

The clear skies haven't materialised tonight so first light for the debayered 1100D will have to wait, I'm afraid.

Same story here. We've been promised loads of clear sky in the last 24 hours, very little of which has actually materialised

James

I've told my 450D to behave or else it will get sent to Gina!

I'd have thought you'd want it calm, relaxed and co-operative, not quaking in its boots

James

Try moving it slowly along. Your air may not be hot enough - mine burns paper.

451 degrees Fahrenheit

James

Or there's this stuff:

http://www.ebay.co.uk/itm/NEW-Double-Sided-MOUNTING-TAPE-Strong-Heavy-Duty-Self-Adhesive-Sticky-Foam-/300606745562

James

No chance of fixing it in place with some hot-melt glue or something like that?

James

Ah, you're right. Sorry. I was getting confused. I'm still suffering from lack of sleep at the start of the week. Can you tell?

James

That is a very neat, professional soution to a long standing problem with these otherwise great mounts....... I would be very interested in buying a kit if you are considering kitting it.

You can buy (most of) the parts as a kit here: http://www.beltingonline.com/heq5-belt-mod-drive-kit-12097

You just need to get the spacer made up one way or another. if and when I get to the point of doing the upgrade and if no-one else beats me to it I will try to remember to make up a PDF of the spacer design for others to use.

James

Welcome to SGL

A good next step would be to buy a copy of Steve Richards "Making Every Photon Count". Read that before spending money on anything else.

James