JamesF

Just when it was going so well, someone throws a great big spanner in the works

I discovered that to write raw non-debayered avi files I can't use the ffmpeg library I have been working with (v1.2.x) because there's no support for that format.  The earliest release I can find support in is v2.1.x.  Having built v2.1.1 and installed it I've discovered that my existing code won't compile against it

James

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

I've only just come across this tutorial after I was having some stacking issues with Registax so a great tutorial James, I've been doing a few full moon images using the 80ED & 1000D recently & after converting them with PIPP Registax was having none of it. I tries Autostakkert & it worked straight away. Does anyone know what the drizzle function does? I only ask as I tried it a couple of times but it said that I ran out of memory, most likely due to my ancient laptop that I'm using.

Oddly enough, I actually use Registax all the way for my full disc lunar images

Drizzle is a method of increasing the effective resolution of an undersampled image by taking advantage of the fact that it can shift by fractions of a pixel each frame.  That's quite useful for DSO imaging where the image tends to be undersampled, but in my experience planetary and lunar imaging tends to be oversampled.  At that point I think drizzle becomes mostly a glorified resize.

There's an excellent explanation of drizzle here: http://www.stark-labs.com/craig/resources/Articles-&-Reviews/Drizzle_API.pdf

James

Hi James ,

Great tute  ... Very clear and concise ... 

I notice that you've used the "Wavelets" in Gaussian mode , might be worth highlighting this as Reg generally shows "Linear" mode as a default and there's a world of difference in effect between them , people may get a bit of a surprise if they ramp the first three layers up to 100% in Linear ... 

Thanks for pointing that out, Steve.  I must have changed that so long ago that I'd completely forgotten about it.  I dread to think what the output looks like if you push those sliders up to 100 in linear mode.

James

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

hi Gina

instead of three cameras and changing cameras, why not use a filter wheel?

so much easier and you only need one camera, no issues with the frame getting rotated when you change.

I have the sx usb wheel and 36mm unmounted filters and they're great.

cheers.

Alistair

You can't use the filters in a filter wheel at the same time

James

Ladies and gentlemen.  We have a second alpha release:

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

James

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

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

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

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

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

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

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

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

*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

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

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

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

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

James

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

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

It's not like you won't be able to sell the Rigel fairly easily if you decide you've made the wrong decision...

James

Off topic... But does the cloud dodger sticker work James? :-)

Only in the sense that it has been dodging clouds for the last two months by staying indoors

James

I think it's a good decision to go with the Rigel in this instance.  If I'd known then what I only found out the hard way after buying the telrad then I might have bought the Rigel myself

Fortunately I picked up the 2" extension second hand, shortly afterwards.

James