Capture software for Linux

[SnakeyJ]

Couldn't swim at the same time as the kids tonight because on Fridays the club takes the entire pool, so instead I took the laptop and QHY5LII, sat in the sports centre cafe and ironed out most of the remaining issues with the camera.  I need to sort out reading the temperature and do some tidying up, but I think the hard work for supporting this camera is all done now

James

Great news James - I know that Torsten gave up on the temperature reading in Firecapture due to problems with the SDK, so think you have done well to get this.    Looking forward to the new release in the not too distant future, but hope the weather clears and you get a few nights out under the stars before hand.

[JamesF]

Thank you, Jake.

I don't know what the Windows SDK is like, but I have the open source one for Linux and it's, umm, well, a bit odd, let's say.  I knew I'd have to re-write the code anyhow as I want it in C and to match my existing API so I've really only used it as reference documentation.  There is some stuff that I just don't get; for example it has some sort of HDR mode that is unpacked into an image in a most unusual manner, but I think I can leave that for the time being.

James

[JamesF]

Got the temperature reading sorted last night before bed

I also (re-)found the source for the MT9M034 I2C driver for the Linux kernel as used on the Beagle Board which turned out to be quite a useful source of information in that I now know what most of the I2C registers are supposed to be.  The two clearly aren't quite identical. but there's some interesting stuff to look into as a result.  For instance, the QHY driver does binning in software after the image has been downloaded from the camera whereas the Beagle Board driver makes it look as if that is possible on the camera chip itself.  It may also support flipping the image horizontally and vertically in the hardware, which doesn't even get a mention in the QHY driver.

James

[JamesF]

I think I'm pretty much there with the QHY5L-II now.  I don't have HDR support enabled yet. but I think that's about it.  I may well leave that for another time as I'm really not convinced it's particularly useful for astroimaging.

I've also been working on adding a settings pannel to show all the camera controls at the same time and as part of that I've managed to sort out support for the "undocumented and private" controls for the SPC900, so in the next release they should all be available like this:

Most are still available in the main window as well via the drop-down, but it is now possible to see all the settings at the same time.

James

[AstroTux]

James,

as you know I've had your software sat on my machine for some time, but have not been able to test it until now :sad: !! I think I've learnt that testing astro-software in the field is not like any other software testing, you have to wait until everything is just right before you can begin . Well on Tuesday night the clouds were not around, all my stuff was easily to hand, nothing else needed adjusting or testing, I was in a comfortable environment at home, nobody expected me to do anything else, etc., etc., so I finally got down to it .

What can I say? Having tried numerous other capture programmes under Linux, yours is easily the most instinctive to use - just look at the pictures, play with the sliders and away you go. Others such as wxAstrocapture and qastrocam-g2 have all the relevant features scattered under different tabs, which can lead to confusion when being used in a dark environment. I always used to find that I had forgotten to do something leading to the capture of loads of unusable data.

No such problems with oaCapture. I was able to get useful data straight away using my SPC900 and the 'little scope' ( AstroMaster 130 ). My first target was Mars and the ability to run at a full 15 frames/sec allowed me to capture lots of information quite quickly, and to perform many runs at different settings - very useful. I then moved on to the full moon and using the focal reducer took just two runs of 600 frames at 10 frames/sec, one of the top half and the other of the bottom half. A quick bit of maths and you can see that I took just 2 minutes of moon data, but it was extremely easy.

Then, on to the processing. Thankfully I didn't have to problem of loading .avi files into Registax ( V6.1.0.8 ) as I'd been through this with you and had installed the utVideo codec under Wine. I decided to start with the Lunar work as I was more confident of the results. This was where the work began!! I did not realise that oaCapture produces so much more data than other Linux capture programmes. Loading 600 frames at 640x480 into Registax, then aligning and stacking them took about 30 minutes on an AMD dual-core 64-bit machine running at 2.8GHz. However, more data is better in my mind.

Just for you, here is the result - slightly out of focus, very crudely processed, then stitched together using Hugin...........

15th April 2014, 600 frames top half, 600 frames bottom half,

SPC900 + 2x focal reducer, Celestron AstroMaster 130

As you can see I need to improve my astro-photography skills, but I'm quite happy with this as it was the result of a test. I just need to remember to use my cornflake packet Bhatinov mask next time. As I'm typing this my other system is chuntering away processing the Mars data, so hopefully something good may come out.

Anyway, many thanks James for an excellently useable application. This is going to be my capture programme from now on. The only improvement I can suggest is support for the SPC900 LX mod .

All the best, and keep up the good work,

Alan

Edited April 17, 2014 by AstroTux

[JamesF]

Thank you, Alan.  I'm really pleased you've found the application so good to use and I think you've done well with that image.  It's not often you see a lunar image done with an SPC900.  It's a pleasure to have such positive feedback.

The next release of oacapture is almost ready and in fact would have been out before now but for some last-minute updates to track changes to the ZWO SDK.  As well as support for the QHY5L-II (at least the mono camera, which is all I have) there is a new camera control window that gives access to all the controls for the connected camera (including the "private" functions supported by the SPC900).  I would attempt to get everything sorted this weekend, but my wife has decided that I will like my office much more if she decorates it this weekend, so I'm busy dismantling everything and packing it up for a few days.  LX mode is on the list of enhancements, but not something I've got my head around yet.  I know Robin (he of SharpCap fame) said that LX mode was a real pain to get working.

For the following release I think I'm probably going to concentrate on support for OSX and perhaps adding a skeleton for support of filter wheels.  Motorised filter wheels are a bit more tricky to handle than cameras as they generally seem to appear as USB-connected serial devices and there's no way for the software to tell for certain what is really on the other end of the serial port.  Part of my intention with oacapture was to require minimal input from the user from the point of view of saying "device X is my camera, device Y is my filter wheel and device Z is the mount" (for instance), so I need a tidy way for the API to be able to say something like "there's definitely a filter wheel connected here" or "these two devices may be filter wheels, but I can't tell; the user must choose".

James

[Fusion]

oacapture is a welcome tool for linux users, I look forward to trying it. I use Linux Disto Astro (don't know if it's had a mention) as well as Mint. Distro Astro has been created with astronomy in mind, the ideal linux distro for oacapture.

[Joseki]

I tried to get oacapture to work with distro astro btw but found it wasn't straight forward (for me). After installing a recent version of Ubuntu it worked fine on that. I haven't commented on my own results with it though as they're pretty disappointing which may be due to problems with using a microsoft Lifecam or my inexperience and I haven't had the chance to properly test it - perhaps tonight - especially since I've now got a windows laptop with sharp cap on to test against (that I would prefer to keep inside). The gui worked well btw other than my issues. I think distro astro is planning to move over to using Ubuntu as a base state in the future.

Sent from my GT-I9300 using Tapatalk

[JamesF]

I think the current Distro Astro is based on one of the Ubuntu LTS releases, but I'm not sure which one.  I know there are kernels that don't support the SPC900 very well and I've found issues with the Lifecam and Xbox cameras in some kernels (and made patches for them).  I'll see what I can find out.

James

[Fusion]

Distro Astro 2.0 updated the kernel from 3.2.0 to 3.8.0 (used by Mint 15 and Ubuntu Raring). I think it's based on Precise.

[Joseki]

On the distro astro release notes page it says distro astro 2.0 uses 3.8.0 kernel, and under "did not make it" they say distro astro will switch to "a new Ubuntu 14.04 LTS base in version 3.0".

Sent from my GT-I9300 using Tapatalk

[JamesF]

Well, having read more on the website it's not entirely clear to me what exactly it's based on, but it does use the same 3.8 series kernels that I have been using for development on Mint 15 and reading between the lines I infer that it's based on Precise, which would make it 12.04 LTS.  There are some oddities that have cropped up recently.  For instance I have built it against libtiff5 which is part of Mint 15, but appears not to be present (nor installable as a package) in Ubuntu 12.04, so those sorts of things do need ironing out.

I'm actually in the process of installing a couple of machines (32-bit and 64-bit) with a number of recent Linux variants as well as around fifteen different virtual machines, so I should have a fairly good idea of what the next release works on and what it doesn't.  I'll add Distro Astro to the list of VMs to install.

Eventually I will get it all built as a package (or several, perhaps) like any other, but it all takes time

James

[JamesF]

On the distro astro release notes page it says distro astro 2.0 uses 3.8.0 kernel, and under "did not make it" they say distro astro will switch to "a new Ubuntu 14.04 LTS base in version 3.0".

I think 14.04 LTS has only just been released, so that may perhaps be a little way off yet.  I imagine it will take some time to get 14.04 shaken down and then to port all the necessary bits to it, set up the repos etc.

James

[JamesF]

I downloaded DistroAstro overnight and installed it in a virtual machine this morning.  It looks like it is based on Mint 13 with MATE, with additional bits from Precise.  I like MATE and in fact that's one of the reasons I use Mint now, but I would be tempted to use a lighter-weight window manager on an astro distribution I think.  I use an Acer Aspire One for testing oacapture and it really isn't happy running Mint/MATE, probably because of the memory footprint.  It works fine with Mint/Xfce though.

James

[Fusion]

I use Mint Xfce on my laptop, I will use oacapture on that, and test on Distro Astro. I have started to put some of Distro Astro's software on to Mint Xfce just need to add some ppa's to update stellarium, gimp and openshot.

[JamesF]

I'll try oacapture out on distroastro for the upcoming release, too.  I've not tried it on Mint prior to release 15 until now.  I would not be surprised if there were niggles with the SPC900 support because it did stop working somewhere between kernel versions 2.6.x and 3.2-ish, but one of my future jobs is to add a user-space driver for the camera as an alternative if the kernel-space one doesn't work.

James

[JamesF]

There is a new release

http://stargazerslounge.com/topic/215690-oacapture-005-beta-for-linux-is-released/

James

[JamesF]

There won't be too many visible changes in the next release as my main goal is to get something working on OSX and it'll mainly just be bugfixes otherwise, but as part of the OSX port I've now massaged the sources into a state where I have exactly the same code building working binaries on 32-bit and 64-bit intel Linux, Raspberry Pi and OSX.  Basically from the top of the source tree it is possible to do:

$ ./configure && make

and it does the rest.  I think the main task remaining is to work out a tidy way of loading the firmware into the QHY cameras on OSX (I can do that manually myself, but apparently the average Apple user can't cope if it doesn't have a point'n'drool user interface  What I'll probably do is just have a bit of code at the start that matches the USB VID and PID values before the firmware is load and runs the relevant commands to do the work.  I also need to sort out wrapping everything up into an installable package for OSX.

I'm probably going to leave one ugly OSX issue present for the time being because I'm not sure how to sort it out yet which is that the buttons in the UI get rendered at what appears to be twice the desired size on Retina displays when they contain an icon.  If I plug in my desktop display then everything looks fine, but there's clearly some sort of scaling issue relating to high pixel density displays somewhere that I haven't been able to run to ground yet.

James

[NickK]

There won't be too many visible changes in the next release as my main goal is to get something working on OSX and it'll mainly just be bugfixes otherwise, but as part of the OSX port I've now massaged the sources into a state where I have exactly the same code building working binaries on 32-bit and 64-bit intel Linux, Raspberry Pi and OSX.  Basically from the top of the source tree it is possible to do:

$ ./configure && make

and it does the rest.  I think the main task remaining is to work out a tidy way of loading the firmware into the QHY cameras on OSX (I can do that manually myself, but apparently the average Apple user can't cope if it doesn't have a point'n'drool user interface  What I'll probably do is just have a bit of code at the start that matches the USB VID and PID values before the firmware is load and runs the relevant commands to do the work.  I also need to sort out wrapping everything up into an installable package for OSX.

I'm probably going to leave one ugly OSX issue present for the time being because I'm not sure how to sort it out yet which is that the buttons in the UI get rendered at what appears to be twice the desired size on Retina displays when they contain an icon.  If I plug in my desktop display then everything looks fine, but there's clearly some sort of scaling issue relating to high pixel density displays somewhere that I haven't been able to run to ground yet.

James

Is the firmware a Cypress based chip download?

[JamesF]

Is the firmware a Cypress based chip download?

It is.

James

[JamesF]

I discovered last night that whilst Point Grey provide their own SDK with all sorts of "proprietary, do not distribute" FUD, their cameras largely seem to implement some sort of machine vision camera standard called either IIDC or DCAM that is related to IEEE1394.  That's rather handy because there's an open source camera library that implements the standard and supports not only (the more usual, I think) FireWire-connected cameras, but also some of the USB ones as well.  I compiled one of the demos from the source distribution and it grabbed frames from my USB Firefly MV quite happily, so it looks as though for the cost of writing a small amount of code to integrate the library with my API I might end up with support for all of the FireWire and USB-connected Point Grey cameras on Linux and OSX

Need to stay focused though.  Must get the UVC stuff for the TIS cameras sorted first.

James

[NickK]

I discovered last night that whilst Point Grey provide their own SDK with all sorts of "proprietary, do not distribute" FUD, their cameras largely seem to implement some sort of machine vision camera standard called either IIDC or DCAM that is related to IEEE1394.  That's rather handy because there's an open source camera library that implements the standard and supports not only (the more usual, I think) FireWire-connected cameras, but also some of the USB ones as well.  I compiled one of the demos from the source distribution and it grabbed frames from my USB Firefly MV quite happily, so it looks as though for the cost of writing a small amount of code to integrate the library with my API I might end up with support for all of the FireWire and USB-connected Point Grey cameras on Linux and OSX

Need to stay focused though.  Must get the UVC stuff for the TIS cameras sorted first.

James

Awesome.. ATIK GP should work too

[JamesF]

That's rather handy.  I didn't realise there were Atik cameras using the same standard.

James

[NickK]

That's rather handy.  I didn't realise there were Atik cameras using the same standard.

James

I'd still use the drivers.. just in case there's some changes/specialisations in there.

Edited June 10, 2014 by NickK

[JamesF]

Well, for this release I had no plans to support any Atik cameras, so anything's a bonus, really.  Perhaps the IEEE1394 library will "just find it" if someone tries.  I haven't poked about in the source so at the moment I have no idea at the moment how it finds my Firefly MV, but it certainly does:

If I can get that working then I think I'll consider anything else a bonus

James