JamesF

Thanks for the reply James, I will see if i can get it running on some sort of fedora for the pi, then report back for you. If it works you'll be a hero As its something I've wanted to do ever since I got my ASI120, then I just need to somehow send the stream to my TV or something like uploading a frame every 30 seconds to a webpage.

I didn't know there was a Fedora distribution for the Pi.  I might investigate that at some point.  I've been using the Debian-based one so far.  I've just been hunting around and found this post: http://zwoug.org/viewtopic.php?f=21&t=1441&p=2028#p2028 which has a reference to an RPi version of the SDK that works.

James

I'm really interested in this James as I'd love to try the combo of my ASI120mc with a raspberry pi which obviously has to run some sort of Linux, and the aim would to be to make it a low power 24/7 all sky cam. Any ideas if your program will run on a distro compatible with the pi?

Obviously high frame rate wouldn't work on the pi but for an all sky cam that isn't an issue.

Cheers

There is one outstanding issue with the current RPi version of the ASI SDK that prevents the application linking, but I believe that has been corrected and should work in the next release, if there's not a beta test version out there already.

This is in fact one of the purposes to which I want to put the software.  Not necessarily this capture program though I see no reason it wouldn't work.  However the libraries on which it is built would be entirely suitable for writing, say, a CLI-based application for capture that wouldn't have all the GUI overheads.  One of the other things I want to do at some point is to make an "analemma cam", to take a picture facing south every day at solar noon for a year.  I envisage a similar approach for that.  Once I get a bit further with the GUI capture application then I'll start thinking about that.  Or perhaps someone else will pick up the baton on that one, who knows?

James

Lots done this evening.  Finished tidying up some small niggles with the SER support, added additional text to make some of the configuration options clearer and finished all the items on my "todo" list for the next release other than a couple that I've pushed back into the next one.

I've also set up a website on which I'll put together some manual pages and so on, but I think that can perhaps wait until after I've actually got the next release packaged up and ready to go.

James

I've been having a bit of a break from "hobby" coding since Christmas.  Work has been fairly demanding and doing a full day's coding only to start again on some more in the evening just didn't have any appeal.  And I wanted to spend some time sorting my C9.25 so I could do some imaging of Jupiter.

Anyhow, I'm now back in the chair and finishing off the remaining items before making another release.  This evening I think I've finished support for SER format output though it isn't properly tested yet.  The remaining things could probably wait for the next release, so I'm going to try to get something out before the end of the month.

One thing I was hoping to have in but probably won't be is support for the ASI034MC.  Apparently that requires an SDK update from ZWO which isn't get available.  Not that I have one to test, but I think if the SDK were available it would probably work.

James

Welcome to SGL

James

Thank you James and Cath   My word, you certainly know your stuff Cath   That would certainly be a brilliant way of doing it if you have the knowledge but I guess I'd better stick with what I know for now

I have to admit that it never for a moment occurred to me that it wouldn't be within your capabilities, Gina

James

Interesting   Does that use Doppler shift to measure the wind speed?

I believe so.  My understanding of the idea is that you measure the shift in both directions across the diagonals of a square (the system being installed in a horizontal plane).  By comparing the shifts it is then possible to calculate not only the wind speed, but also the direction.

James

I've always fancied trying to build an ultrasonic anemometer, but I think may be rather more tricky than it sounds at first.

James

An EQ5 would probably ne the minimum mount for this telescope. 

Have to agree with this.  The EQ3-2 is pretty much on the limit with the 127 Mak.  I'd not want to put anything heavier on it.  You might find a used EQ5 for around £150.

Failing that I might be tempted to try to find a tubular leg tripod and make up some sort of fork mount from timber to fit on top.

James

Oh, I forgot to mention.  This may be helpful:

http://www.tanstaafl.co.uk/2012/03/focal-ratio-capture-length-planetary-imaging/

James

Thanks for this tut it has taken my planetary from zero to hero.

By the way, I need some advice on imaging Jup.

(I too have a 127 Mak cas at f12)

What is the longest to expose before rotation effects?

Is it better to Barlow up to f24 or f48?

I usually capture images as bmp instead of video.

And don't use raw as debaur is complex and does it at value on a stack of 2000+?

I'd not suggest capturing longer than three minutes, but it depends on the focal ratio and camera that you're using.

I'd suggest f/24 would be a better bet than f/48.  The latter is likely to make it tough to keep the target on the camera sensor.  Again it depends on the camera though.

I prefer a single file for capture as it removes the overhead of opening and closing files (and video also tends to be a lot more compact than bmp).  Capturing at high frame rates is liable to make disc IO a bottleneck.

There may well be dozens of proposed algorithms for debayering/demosaicking images.  Some are fast, but don't tend to produce a particularly high fidelity image whilst other slower methods produce much better results.  Because time is a factor and processing power is limited the implementations in camera firmware tend to be at the lower end of the scale in terms of quality of output.  Doing the same processing externally may well produce better results regardless of the number of frames captured therefore.

James

Ps last attempt at 990 images.

http://stargazerslounge.com/uploads/gallery/album_2903/gallery_32740_2903_5622.jpg

I'd try rebalancing the colours slightly on that one, but there seems to be plenty of detail there to start with so I'd say you've done well with that one.

James

A question for James, I've tried using this program doing a full lunar image but AS!2 keeps cutting a huge chunk off it for some reason. I've tried different settings but not having any joy, any ideas?

I'm not sure why this should be.  I process my full disc lunar images a different way because they're quite large and AS!2 doesn't seem to handle large images very well:

http://stargazerslounge.com/topic/184192-full-disc-lunar-imaging-with-a-dslr/

James

Surprised I only just read this but what a fantastic post James  ! 

My only comment would be that when stacking DSLR images, it often produces a white outline around the moon. This used to wind me up. 

I learnt (from someone else on twitter) that before aligning, if you click on 'show advanced controls', then uncheck 'predict track'...there will be no bright white outline! 

I suppose you can also use the deringing tool in wavelets. 

Not quite sure what effect 'predict track' has but with centred and cropped images from PIPP it has prevented the white outline, for me at least. 

I do sometimes get that problem with planetary images but I don't recall ever having it on a lunar image I have to say.  It's entirely possible it's partly related to exposure time and image scale or something like that.

James

You should be told you need to "do all" before saving if you haven't already.

Not sure why the image is pixellated in the first place though.  Have you done a fairly heavy resize on it?  I think the "zoomed view" is just that -- it affects what you see on the screen, but doesn't do anything to the image itself.

James

mate this is so helpfull thankyou for taking the time to do this!

You're very welcome

James

Impressive indeed.  And unlike a christmas tree, it won't drop needles or sap all over the carpet.

James

Hah!  I knew I wasn't too far off  There are still plenty of niggles to sort, but I have now captured a raw greyscale avi from the QHY5 at 1280x1024 using the CCTV lens from my ASI120 (which doesn't have enough inwards focus nor a large enough image disc):

Seems about the ideal time to call it a night

James

I'm making progress with the QHY5 support now.  It's a hideous mess though  I can't find any documentation for the QHY5 firmware despite the fact that a number of open source applications using the QHY5 exist and therefore the documentation must presumably be around somewhere.  The person who wrote the firmware seems to have disappeared off the face of the planet as well, so I'm pulling things together by comparing the various applications and trying to extract information from them which is fine apart from where they disagree

Still, all I have to do now is to actually grab the image from the camera and pick it up to return to the calling application, which kind of sounds like it ought to be pretty much everything the code does, but in reality I think (hope it's going to work out as about twenty lines of code from a total of around a thousand.

The QHY family of cameras seem to have interfaces that are almost, but not entirely completely different which is making for fun in terms of structuring the code.  I really don't want a QHY5 interface, another for the QHY5v, another for the QHY5-II etc. etc. if I can avoid it.  That's meant I've actually ended up structuring the code closer to the way I should have done it to start with, so perhaps it's not as bad as it could have been.  I can see a re-write of the main camera library interface coming fairly shortly though, which should lead to a simpler, cleaner and more efficient system.  At least until I find the next camera that doesn't quite fit

James

For that much I'd at least want a few shades of grey as well as black and white.

James

Well, I've now added a bilinear debayer method and support for the 8-bit raw mode of the ASI120MC (so hopefully all the ZWO colour cameras).  That pretty much leaves support for the QHY5 as the only major thing I wanted to do for the next release.

The bad news is that whilst I was doing the additional support for the ASI120 I had one of those moments where you think "If I'd known then what I do now, I wouldn't have done things this way"  A rather neater way to handle setting the various camera controls and features has occurred to me.  I think that can wait for a while though.  I was half-expecting that it would happen anyway as the greater complexity of implementing support for different features of such different ranges of camera functionality became more obvious.

James

And just before I went to bed last night I managed to get everything working.  With GBRG and GRBG handlers written and some config options to switch between them I found that the camera is GBRG and I have a nice colour image.  Big step forward

This actually makes my "todo" list for the next release longer, because it means I now have little reason not to add handling for the ASI120MC 8-bit raw mode.  I might leave the 16-bit raw mode for another release as I don't think much of the additional data is actually very useful.

James

Oooh, some days...

I've spent this evening working on picking apart the bayer matrix, which is a little hairy even doing just the simple "nearest neighbour" algorithm.  The camera driver announces it as BGGR, which I assume means that the pixels are arranged thus:

BGBGBG

GRGRGR

BGBGBG

GRGRGR

But that clearly wasn't working even though I'd tested it as functioning correctly.  So I added an RGGB handler, but that didn't work either.  Searching the web in desperation it appears the camera lies about its colour mask and that it may in fact be GBRG.  I guess I'm writing yet another decoder then.  Never mind, I'd have had to have done it at some point.

I was hoping that I might be able to handle the layout just from the data provided by the drivers and not have to ask the user for the mask arrangement, but it looks like that isn't going to work

James

Well, I just can't help myself

The atmosphere was pretty soggy so I packed up an hour or so ago.  Whilst AS!2 chunters through my capture runs I did a little more coding and now have imges from a TIS colour camera displaying on-screen as an non-debayered greyscale image and being written to a file which I believe is raw BGGR8 data.  Unfortunately all the tools installed from my Mint 15 distribution are built against a much earlier release of ffmpeg, so I can't actually test playback of the saved file yet.  I might have to push it over to Win7 and see what AS!2 makes of it.

I should probably also revisit the ASI colour cameras now as at least some allow non-debayered capture.  It's added to my list of things to do for this release

I've been thinking about debayered colour images from cameras that support non-debayered output.  I think if the camera will do RGB and the user wants debayered data I'll just push the camera into RGB mode.  If the user wants a debayered image in the preview but to save the raw format then I'll debayer on the fly using a function from a separate library.  There seem to be many different algorithms for debayering, some of which are slow and computationally expensive but produce better results.  A library would allow me to also use the code a debayering application that could be used to try various different algorithms and then use the one producing the best output.

James

Haha!  I found a web page giving details of how to translate the old style stuff into the new.  Back on track again!  Not much chance of any more work being done tonight if the sky stays clear though.

James