Capture software for Linux

[cgarry]

I did think that would be quick for another release...

I think you should go with your plan of getting the major functionality working before doing your next release.  Even if your release notes state exactly which controls do and do not work, I can guarantee that most users will not read them and then try and use the controls.  I think that the best approach is to disable any controls that are not implemented so it is obvious to the user. 

Keep up the good work!

Chris

[JamesF]

I've spent a couple of hours this evening trying to get my head around autoconf & friends.  I might have to close that browser window and tip-toe quietly away pretending I'd never seen it.

I've used autoconf for building other people's software more often than I can imagine, but to try to retro-fit it to your own, ye gods!

James

[Gina]

Forgive me if I've missed something James, but are you just going for webcams or are you going on to DSLRs and/or astro CCD cameras.  I would like to use a Linux box for my no.2 imaging system - maybe a pair of DSLRs and QHY5 guide camera.  Current thoughts are one 450D converted to mono, set-point cooled and with built-in filter wheel and the second an 1100D left as OSC (just filters removed) and set-point cooled.  They would have lenses attached for wide field with the focus sleeves connected to stepper motors with timing belt and pulley and controlled by Arduino.

Are you going on from image capture to guiding and maybe focus control?  This would be an enormous project I realise

[JamesF]

My intention is to create multiple components, Gina.  One will be a library/libraries that provide camera support through a common API, in principle allowing anyone to write an application that in theory will "just work" with whatever camera is connected.  I see no reason (other than camera manufacturers' unwillingness to work with the open source community) that this shouldn't work for what are usually considered "long exposure astro cameras" as well as "fast frame rate planetary cameras".  In fact whilst some webcams can stream data continuously to the host computer not all do, and not all the more dedicated planetary cameras do either.  This second group work in a manner far more similar to the long exposure cameras, where the host repeatedly requests a single exposure.  Or so it appears to me thus far.

I've started with webcams particularly because I'm fairly familiar with the Linux V4L2 interface.  In fact before it became obvious how much time and work would be involved I was considering writing V4L2 interfaces for some of the cameras I'm interested in.  As that's not realistic for now and because there are userspace libraries for quite a few cameras, albeit completely incompatible ones, I'm going to stick with userspace for the time being.  I also want to be able to use cameras for all sky imaging and other applications that are more suited to webcams and/or fast frame rate cameras, so it's an obvious place for me to start.

Having made that decision this capture application was an obvious choice to write alongside, as writing libraries isn't exactly thrilling when you see no output for your pains.  Whilst it's probably tailored more towards planetary capture at the moment there's probably no reason it wouldn't work for longer exposure imaging.  I've had that in my head for a while and haven't yet come to a decision regarding whether it makes more sense to use a separate application for that or to combine all the functionality into one.  I have tended to view planetary imaging and DSO imaging as two different processes intuitively, but I'm not sure that's actually true.  It may just be a preconception that's reinforced by the fact that existing applications seem to do one or the other.  It could be that the same core application would work fine given a better-tailored set of default controls.

DSLRs are the elephant in the room, really  In principle it would be very nice to support them with the same interface and I'm aware of the existing support on Linux, but they're far more complex than astro cameras and I understand too little about them.

Still, if I can get far enough for other people to see it and they believe it's a useful project then perhaps some might join in and help move things forward.  Stranger things have happened

James

[Gina]

Thank you James

[JamesF]

And of course once you're done there'd be no reason not to extend the API to provide an interface to libGinaCam

James

[JamesF]

Been quite a slow week this week thanks to volume of work, but I've managed to get a bit done.  I have a build system that appears to work now, though it doesn't autoconfigure, and I have the capture directory selection box coded (but not yet tested).  Next I think is the limit box and then the ability to run sequences of captures.

James

[JamesF]

I was thinking I might have to use my application for real tonight as the Win7 installation on my laptop threw a wobbler when I booted it for the first time in a month or more this morning.  I updated to beta 14 of FireCapture and it crashed after failing to find a camera

Fortunately I've got the capture time limit working and I'm nearly there with the autorun feature, so it's probably quite usable.

I think the weather might be having second thoughts about this evening's clear spell however

James

[NickK]

I think the weather might be having second thoughts about this evening's clear spell however

James

There's a point, a brave point, when you make the switch to use your own software to capture with the precious clear nights..

First you find all the awkward defects, then the missing functionality, and slowly it becomes more robust.. and finally you start getting annoyed at 3rd party software. 

[JamesF]

A bit of an update as I've been quiet(-ish) for a week or so thanks to work

I have capture time limits and repeating capture runs sorted now, plus a few other bits and pieces.  Of the twenty-five or so items I had on my "todo" list for the next release there are eleven left and a few of those are really just refactoring the code and tidying up places where in retrospect I started off the wrong way but I wanted to continue and get stuff working rather than start from scratch, so they're not a major requirement for another release, just not code I can be proud of

I'd quite like to get another release out this month, and of what's left I think the most desirable functionality is to be able to save the current camera settings and restore them later (or next time the application is run) as different profiles.  If I can get that sorted it would remove a few outstanding items from the list and then I think I'll use that as the basis for a new release.

James

[themaninthesuitcase]

 just not code I can be proud of

No such thing!  Only code you don't hate, yet. 

Sounds like your getting along well though.

[JamesF]

*sigh*

You always end up making more work for yourself, don't you?

This evening I have implemented the code for loading and saving the application state on startup and exit and it appears to work quite nicely.  Unfortunately it's also highlighted how many of the configuration options I should have set up to be saved in the config but haven't.  So now I need to go through them all and make sure they do in fact get saved.

Dealing with saving the program state also reminded me that it is desirable to save the main control settings to a text file along with the captured data.  I think that has to go on the list before the next release.

So, this evening I have written enough code to remove two items from my "todo" list, then had to add two new ones back as a result

James

[JamesF]

And after looking fairly hopeless, it appears the Imaging Source cameras might well be supportable with a little work.  The colour ones don't provide debayered output though, so I'd have to implement debayering too.  Oh, decisions, decisions...

No chance of getting much done tonight though.  For the first time since 4th September the sky is clear and hopefully Jupiter should be out to play later...

James

[SnakeyJ]

Good luck with some PI James, you've worked long and hard on this and deserve a night off!

I suspect the good conditions will be short lived, so make the most

typed on my mobile with Tapatalk

[JamesF]

Things seem to go grindlngly slowly when you get to the last few bits and pieces

I'm down to the last seven items on my "todo" list before the next release, four of which weren't there a week ago but have been added as I've discovered odd issues or thought "Oh, I really *ought* to have that that".  I've done all but three items that were on my original list for the next release, plus a few more besides.  I'll get there in the end...

The biggie that's left is still the saving of existing settings as a profile (and reloading them).  I've done a bit of work around that and I'm currently finishing off filter management which is similar but much simpler.  It won't be possible to have the application control a filter wheel (yet , but it will at least be possible to select a filter from a drop-down and have that recorded with the output file and in the filename if desired.

I really do want to get a release out this month to keep the momentum going, but I'm going to struggle to complete everything on the list in the next two weeks.  Depends how many clear skies we get

James

[JamesF]

It appears that I am pretty much done.  I have one irritating bug outstanding that is easily worked around and may not even get triggered by most people (and in fact doesn't relate to the capture process at all) so I think I'm going to leave that for now.

Now I just need to package up the binaries, write up some build instructions and package up the sources and I can make another release.

James

[JamesF]

Woohoo!

As I type I am capturing images of Jupiter from my ASI120MC   I'm two runs through a sequence of ten at the moment.  Of course I don't know the data is any good, but I can now at least say I've used it for real.  Tomorrow (or after I've slept) will be image processing day...

James

[JamesF]

I've just come up with an idea for another feature, too.  On notebooks with small screens it would be quite handy for focusing to be able to say "hide all the controls and use as much of the screen as possible for the preview image".

There's something else niggling at the back of my head too, but I can't quite put my finger on it yet.

James

[JamesF]

Oh, yes.  Offer an option to display the temperature of the camera in F rather than C for those people who still use old money.

James

[SnakeyJ]

Look forward to seeing your Jupiter image James - hope it;s better than my efforts tonight.   Nice to see you out field testing though

[JamesF]

It was very nice to be out and have the opportunity to test it  I'm just transferring the files from my notebook now...

James

[JamesF]

Here we go.  First real-life test of my code.  Colour me rather chuffed

http://stargazerslounge.com/topic/200636-first-jupiter-of-the-season-and-more/

James

[JamesF]

Ladies and gentlemen.  We have a second alpha release:

http://stargazerslounge.com/topic/200733-second-alpha-release-of-linux-capture-application/

James

[JamesF]

And I've already kicked off on the next version

This evening thanks to the cloud I've been picking off some of the easier items on my "todo list" for the next release.  Mostly just tidying up, really.  I'm building myself up to the adventure that is non-debayered data in the TIS cameras

James

[JamesF]

Well, I've pretty much done all the easy stuff on my list of things to do for the next release so I thought tonight I'd better face up to some of the harder stuff and started looking at what's required to support the Imaging Source cameras.

I now have a rules file for udev and a configuration script that allows the cameras to be recognised by the UVC driver for V4L2 and run down a couple of bugs in the code meaning that all the mono cameras should work.

This means there is no more avoiding the horror of handing non-debayered colour frames which is I think all that's required to support the colour cameras.  I haven't decided yet whether I should separate the handling of the preview window and the saved image data for debayering, so it is possible say to display a debayered image in the preview but write either raw data or debayered frames to the output file.  I guess of the image isn't debayered in the preview window then it's most logical to treat it as a greyscale image.

James