Capture software for Linux

[JamesF]

I've just checked the sources for the IEEE1394 library.  There's a list of USB vendor and product IDs for cameras known to support IIDC over USB which at the moment is restricted to the Firefly MV (colour and mono) and the Chameleon (again colour and mono).

I'd guess dropping the appropriate VID/PID in for the Atik GP might work, but that might be something someone else has to do, though it wouldn't be hard for me to add the data to the code.  I'd just have to use a bespoke build of the library.  As I do that for ffmpeg, libusb and libuvc already that wouldn't be a big deal.

James

[NickK]

Hmm good point..

[mitchelln]

Just tried 0.0.6 and I now have colour with my QHY5-II C Fantastic job James.

Only issue I'm having is it is not saving settings. I set the Bayer format to GBRG and click save, but next time I open the app its back to RGGB.

Looks like tonight is going to be clear so I can give this a go. One less bit I have to use Windows for!

[JamesF]

That's excellent news.  I'll look into the matrix format issue.  It may be that I forgot to save it or something daft like that.

James

[JamesF]

Further to my posting a couple of days ago, here's a screenshot of my IIDC Firefly MV capturing images:

Rather pleased with that I have to admit. especially as it's unencumbered with any of the Point Grey software and its associated licensing conditions.

There's still some work to do and I've made a few unsafe assumptions about how the cameras work that are probably ok for this particular application at the moment but will need sorting out in the future.  And it's not tested on OSX yet, though I see no particular reason that it shouldn't also work there.  Shame I don't have a firewire astro cam to plug in and test with it, but until recently I didn't even have access to a machine that had a firewire interface any more.

James

[JamesF]

Well, I pretty much finished support for my Firefly MV this evening, dropped the sources on my MacBook and they built and ran first time without errors so I'm quite happy with that.  Pending some regression testing and a couple of small bugs to look at I think it might be time to start looking at another release.

James

[JamesF]

It's been a quiet few weeks what with the children being off school and us going abroad for a holiday, but now I'm home again and got through all the stuff that inevitably seems to build up whilst we're away I've settled down to some more work on oacapture.

I've added the small amount of support required for the new USB3 ASI120 cameras, which was pretty trivial to be honest.  Looks like it could be an interesting camera, especially for solar/lunar imaging.  Nice high frame rates at full resolution.

Then rather than working on my own code I've been twiddling someone else's.  Quite a few other people's, in fact.  It turns out there are three of us who had taken an open source UVC library and extended it (myself to support the TIS cameras), so I've been merging all of those changes together to fold back into the original author's code.  I did have an ulterior motive however.  Now I'm all done bar one required bugfix for an issue that was already in the UVC library, and I've written some code to convert YUYV and similar video format frames to RGB, I've added support for the MS Lifecam.  That's now working on Linux (though it probably already would have done via the V4L2 interface), but should also now work on OSX.  As soon as I have the code cleaned up a little I'll give it a go.  It may also be that I can support the Xbox camera on OSX, once I can work out exactly what format it is using to transfer the image.

OSX support for the Lifecam and Xbox cameras doesn't of itself sound that exciting, but it will mean that there is a cheap native astro-imaging option for OSX.  And let's face it, by the time you've sold your firstborn and bought a new MacBook there's not much cash left for anything else  The support for video format frames also takes me one step closer to one day perhaps supporting the SPC900 on OSX.

I've also made a few UI changes that allow the various control panels to be docked either at the top or the right of the display, or even dragged off as separate windows altogether.  Hopefully that should help a bit on small displays.  It's also possible to hide all the controls so only the captured image is displayed, giving the largest amount of screen available to help with focusing on low resolution displays.

James

[paulyg]

I've just been trying oacapture 0.07 on my old atom based netbook (Samsung N210 running Xubuntu). Everything seems great in preview mode: I'm getting decent frame rates of around 10-20 FPS and the application itself looks great!

However, once I attempt to write to an avi file, the number of dropped frames rises massively and I seem to be getting around 1 FPS or less on the output file. Interestingly, the preview still looks fine at this point.

It seems like the disk can't keep up once data is being written. Does that sound right to you? I know the atom is underpowered, but I thought it would cope better than this. Is there any kind of logging I can enable to see what the chokepoint is here? Has anyone else had success using this kind of hardware?

Paul

[JamesF]

I have a couple of Aspire One netbooks and have managed to capture useful data for an image of Jupiter with it.  Either the hard disk or its interface do seem to be quite sluggish on these small netbooks though.

What camera are you using for capture and at what resolution?

James

[paulyg]

I'm using an ASI120MM at full resolution - I will try a lesser resolution (although I imagine that will drastically cut down the FOV)

[paulyg]

You're right: cutting down to 320x240 does drastically improve things.

[JamesF]

That does make it sound like the disk is likely to be the problem.  Did you have a particular target in mind for capture, or was this just for experimentation for the time being?

James

[paulyg]

Just experimentation for the time being. The UK skies are devoid of good targets at the moment - my scope is very slow and my mount is Alt-Az so I'm pretty much limiting myself to planets and the moon.

Many thanks for your help though.

[JamesF]

Ah, right.  Planetary may well be ok anyhow, as you can probably come down to at most 640x480 if your tracking is good (unless you're using a C14, perhaps .  Lunar is going to be more troublesome though, unless you're just targeting specific features.

James

[paulyg]

I just had to google the C14: That's a big beast!

I'll stick to my dinky (and cheap) Mak127 for now 

[JamesF]

I just had to google the C14: That's a big beast!

I'll stick to my dinky (and cheap) Mak127 for now 

Something to aspire to

Using the Mak with an ASI120 you can probably go to 400x400 on Jupiter if your tracking is good.  That should be plenty big enough.  The other planets will all be smaller.

James

[NickK]

Hi James,

OSX only but .. I've just upgraded to 10.9 and have been reading through the AppNap documentation - have you checked out NSProcessInfo API in 10.9? One of the methods relates to categorising processing being done by the application (ProcessInfo beginActivityWithOptions:reason: etc) but also there's a section in the documentation about I/O prioritisation for latency such as video I/O.

Although I think the Prevent AppNap finder option also helps but I think this will eventually become 'less optional'..

Still digging..

Edited August 20, 2014 by NickK

[JamesF]

For the  time being I think I'm going to ignore it, Nick

It looks as though there's a problem with FireWire cameras that I want to get sorted and I'm in the middle of improving the recording profile management.  Once that's done I'll get another release out, especially as I need to do one to sort out support for the ASI USB3 cameras.

After that I want to work on filter wheel support and whatever else is necessary to allow me to move to using it for RGB imaging of Jupiter on its return in late Autumn/early Winter.  I also want to think about support for the Lodestar and the modifications required to create an all-sky cam/meteorcam version.

Even without oaCapture I seem to have 101 other projects on the go at the moment, so lots of new stuff is just having to go at the end of the queue

James

[MCinAZ]

Hi James,

  It appears that you've done excellent work and made remarkable progress on oaCapture in the year since you started work on it. In addition to planetary imaging, your program would be well suited for capturing speckle interferometry data sets. As with planetary imaging, speckle interferometry is a technique which combines data from many very short exposures of double stars to overcome atmospheric seeing effects. The processing steps are dramatically different, however the basic data capture task is similar. Cameras based on the ON Semiconductor (formerly Aptina) MT9M034 sensors, such as the QHY5L II and ZWO AS1200MM show signs of being very good choices for this type of work.

  As with most scientific imaging tasks, lossy compression is detrimental. In the oaCapture documentation, it is mentioned that TIFF image export is supported. For speckle interferometry, FITS files are ideal, however TIFF images can be post-processed to FITS without too much difficulty. Using your ZWO camera, could you provide an estimate of the frame rate one might expect with a very short (e.g. 1 ms) exposure time when exporting to TIFF. In addition to full-frame images, the frame rate for a relatively small ROI, say 200 x 200, would also be useful. I realize that there is some dependence upon the capabilities of the host computer, but any information you might provide would be valuable.

  -- Mike --

[JamesF]

It's on my list of things to do to support FITS, Mike.  It can jump up the priority list now  I don't believe it should be too hard if I use one of the existing libraries.

I'll try to get some performance numbers later today.  It strikes me that neither TIFF nor FITS are ideal for high data rate images because of the overhead due to opening and closing lots of files (perhaps more so on a traditional hard disk than SSD).  It might however be possible to write unmodified data to AVI or SER files and post-process that to FITS.  It would certainly be interesting to see the difference in performance.

James

[JamesF]

I've just tried the version of oaCapture that will be released in the next few days.  On my Core i5 desktop with 12GB RAM and a very average hard disk using the USB3 ASI120MM-S with a capture size of 320x240 (the total number of pixels has to be a multiple of 1024) I get around 225 fps writing the output as either an AVI file or individual TIFF files over a period of ten seconds.  I've not tried on my MacBook (which has an SSD), though I suspect that it won't be much different as I don't that much greater a frame rate when the frames aren't being stored.

James

[JamesF]

It does strike me that performance with TIFF or FITS files may degrade as the capture period increases because of the increasing time to create new directory entries in the filesystem for new files.  If you're thinking about capturing thousands of files or more, it may be sensible to add an option to split the output files into subdirectories with smaller numbers of files in each.

James

[MCinAZ]

Hi James,

  Collective reply to all three of your posts. First, as I mentioned, FITS would be great but I can post-process to create files in that format from TIFF. If you eventually add FITS support, that would be excellent, however it probably doesn't warrant special priority. Second, I was looking for something in the range of 50 frames per second. The number you determined is way better than good enough. A back of the envelope calculation indicates that more than 10,000 320x240 frames could be stored on a 1 GB RAM disk, so that may be an option for keeping I/O overhead from being a significant factor. A tmpfs file system is trivially easy to configure, and so long as one copies data to non-volatile storage after an observing session, that ought to be a reasonable path.

  Latest word I've gotten is that QHY has a cooled camera in the queue which may be a bit better for the type of work I'm interested in. I may wait a few weeks before acquiring a camera, but I hope to be using oaCapture at such time as I do. (Or, I may just get impatient and buy either an AS120MM-S or QHY5L II to get started, and move to a cooled camera later if there's sufficient reason to do so.)

  Thanks for the prompt reply to my inquiries.

  -- Mike --

[mitchelln]

The QHY5L II is proving to be a great planetary camera. I got this using oacapture. Thanks to James for taking the time to write this great app

Edited September 12, 2014 by mitchelln

[JamesF]

That looks excellent.  Well done.  That was with the colour version of the camera?

James