Martin Meredith

I can see beautiful stellar discs everywhere for the first time in 8 years. Is that a good enough reason?

Real world data point: I recently bought a small pixel camera (ASI 290MM) which coupled with my 800mm FL scope puts me in the slightly oversampled range, but I'm mainly using it binned 2x2, which places me in the middle i.e. critically-sampled. For many years I've used a large pixel Lodestar with the same scope, and astronomy.tools places that slightly in the undersampled region. My practical experience so far (~100 DSOs observed with the new cam in various seeing conditions) is that astronomy.tools is spot on. In fact, I would go in the opposite direction to what I understand is your proposal and state that the 800mm/8.4um pixel combination is actually rather badly undersampled at times. There is really no comparison in terms of star shapes. It's been a bit of an eye-opener actually. Martin

What do you see when you click on library? Has it created the masters? That's the first step to thing to check for.

I've uploaded v0.5.4 now. To upgrade, type pip install --upgrade jocular Main changes: [1] I've updated the ASI drivers to the latest version and included both 32 and 64-bit Windows versions that are automatically selected (no need for the user to choose) [2] Fixed an issue with cross-device watched directories (eg monitoring a directory being written to by a remote RPi) [3] Subs are now represented internally as float32 rather than float64. This will mainly help those with limited RAM/no SSD. [4] Fixed a few other minor bugs BTW If you can't select the S or W controls or find any other kind of overlapped widgets, it is almost certainly due to the widgets in the DSO panel (top left) overlapping with these controls. This can occur on small screens. The solution is to close the DSO panel when selecting those widgets. I'll look into more creative placement options. Thanks to all for your feedback so far!

Lodestar or ASI 290? Good question! I think perhaps seeing was better when I took my short of NGC 2022. What's is certainly true is that the ASI 290s smaller pixels are much better suited to my focal length than the Lodestar and this really helps for PNs if the seeing supports it. The downside is fretting about gain. The last few sessions I've left it on unity gain (110) which I think will be my default setting until I understand what if any advantages of upping or downing the gain are.

I'll add the upgrade to the web page but I had a feeling just doing pip install jocular might be enough to achieve that. Could you PM me the log that you'll find in joculardata/logs please? That will help identify any issues with the flats. I don't use max age any longer because I don't think it is necessary -- what it does is find the closest in age if there is a choice of suitable flats. I use closest because you might be reloading images captured years ago... (in which case keep the flats...). I moved the ring dimming control (and renamed it transparency) to conf/Appearance. If inconvenient it could be re-added, but I was cleaning up the main eyepiece based on my own usage... The plan is to add rather more information in the imstats, including FITs headers (for subs/masters) and that will give you the pixel dims. By the way, in principle annotation now makes use of any pixel height and binning info in the FITs header so you don't need to provide anything other than focal length to the platesolver. For those with multiple cameras (or with a colelction of previous observations taken with different cameras), this saves messing about with pixel height. Yes, definitely interested in discussing your noise reduction method (and happy to incorporate it into the code if appropriate). One other (potentially temporary) simplification I made was to bad pixel mapping. This is now done on each sub and is really just hot pixel removal (no mapping). The BPM started to get rather cumbersome with multiple sensors and ROI. There is a new outlier rejection threshold (in sigmas) that controls what is considered a hot pixel. Let's see how this works and if necc. I will go back to building maps. (the key difference is that a hot pixel formerly had to be present on multiple consecutive subs to count as one). Martin

Thanks Tony. I hope the watched functionality is still all OK too though it is challenging to cope with all the various FITs that are being thrown at it... I don't expect the native Ultrastar to work first time but it will be interesting to hear of your experiences (and if you don't already have libusb you might need to build it using 'brew install libusb'). Re binning/OSC/ROI etc, the plan is to rationalise things so that these options can be applied to all captures ie in a uniform camera-independent way, which is not the case at present where, for example ROI is only available for ASI cams, and debayering is only in place for watched captures... It needs a little refactoring but is coming soon.

Very nice captures Bill. I can see a vague pinkiness in the HH. If you use the gamma stretch it tends to bring out more colour, in part because the colour stretch is also gamma and well-matched. I've been touring around Orion myself but for some reason didn't pay a visit to the Flame Nebula. is the blue from that neighbouring bright star (Alnitak?) Martin

Some updates after initial user testing: * Windows users wishing to use ASI cams need to download the ASI drivers from here * Mac users need to ensure that the libusb-1.0.0.dylib is present and findable on their system. I may bundle this in the next release. * anyone monitoring directories on another physical device (eg rPi) will find that the FITs are copied rather than moved, so the same FITs will get sent over and over again. This will be fixed soon. These and a few other minor issues are now mentioned in the installation instructions on the website.

You are quite right. It looks like it didn't package those files, presumably as I didn't specify their extensions in the manifest. Give me a few mins to sort it.

I had a similar question having just obtained my first CMOS camera (ASI 290MM) and that reply really helps - thanks Alan. In particular, there's quite a lot of information on the web about changing the offset every time the gain is changed, which sounds like a nightmare... so its good to know that it can be set at a fixed value with a reasonable certainty that black clipping won't occur. I have mine set at 25. I also tend to use unity gain only, no doubt suboptimal but I'm finding it gives me results close to what I get with a CCD and an absence of stress! Martin

It comes with the distribution so you don't have to do anything (I hope!) Specifically, it is this one that gets selected if you're on a Mac: libASICamera2.dylib.1.18

At the moment, yes, but the plan is to remove that restriction. I didn't want to do it in this release without thinking through any possible downsides. I think if hot pixels are properly dealt with then it will be OK to do this. Since getting a CMOS camera I have been somewhat overwhelmed by the potential need for multiple calibration frames, so anything that can be done to redeploy them will be done! What's your feeling about offset differences between calibration frames and lights if all the other parameters match up?

Hi Steve Not at present but if I can implement it I will. One problem is that for various reasons I'm determining ROI during the framing stage, so those captures would need to be done in Jocular. What I want to do is further rationalise the whole binning/ROI stuff so that it is camera-independent (at which point it will also apply to 'watched' captures). By the way, the watched folder functionality has changed a little in ways that I will try to document before the month is out. I've only been able to properly test the darks so far so it will be interesting to see how you get on with flats. There is nascent support for choosing between bias and flat-darks, and a placeholder for using a constant a la Siril too. I tend not to use flats myself but when I do I use twilight flats, and I just haven't been around at twilight recently... Good luck! Martin

Here's a shot of Hubble's Variable Nebula from last night with decent seeing. I've not looked at it in colour before so wasn't sure if the brown edges and smoky blue interior were 'correct', but they do seem to concur with the Hubble shot https://science.nasa.gov/ngc-2261-hubbles-variable-nebula So: has it changed much in the past year? I still see the pair of 'blue streamers' that were present in my 2017 image (edit: blue in this shot, not in the 2017 monochrome version!) This is a bin2 shot at unity gain Martin

The new release of Jocular is now available. This is a major new version which supports ASI cameras natively across the 3 major operating systems. ROI/binning are supported for ASI cams, and the calibration library applies automatically to ROI-ed images. There are changes to the GUI to incorporate material design widgets, silent logging, easier installation and a host of other small changes including being able to change the location of the watched directory, though nothing major in terms of processing or object databases. Oh, and it has (annoying) tooltips for which the most important information is probably how to switch them off (conf/Appearance...). For further details, see: https://transpy.eu.pythonanywhere.com/jocular/ The download (~29M) now comes bundled with a couple of example captures. I've developed and tested this on OSX using an ASI 290MM. I haven't been able to test on Windows but in theory it ought to work. Please let me know (I'm sure you will!) of any issues 🙂 Martin PS There is also (highly) experimental native support for the SX Ultrastar which I haven't been able to test, so any feedback from Ultrastar users on Macs would be appreciated (pretty sure this won't work on Windows but who's to say). Similarly untested is ASCOM filterwheel control. I'm planning to support ASI filterwheels in the near-ish future.

yes, and yes 🙂 The native ASI support is all there (I've been using it for a week or so with my new ASI 290mm) but I need to add the extra gain/offset/ROI params into the calibration-handling part so that the automatic calibration does the right thing. I expect to be able to release the next version next week. Martin

This is NGC 246 in Cetus (also known as the Skull) not far from its transit at around 33 degrees, again under a near-full moon.This is a rather large object as PNs go and yet still reasonably bright, at least around part of the expanding edge. This one I have to revisit under moonless conditions. One feature that struck me as I was observing was that the central star appears (optically) double. I thought at first that this was a tracking issue but as the colour built up the colour distinction became clear, and checking other images indeed there is another star right next to the blue central star (a mag 11.8 white dwarf). 10s exposures, gain 100, bin 2. Martin

Definitely a clearer image, and in a 3rd the exposure time. Last night with an even brighter moon I looked at the Horsehead in H-alpha, M74, Abell Galaxy Cluster 151 (containing VV 935), a rather startling planetary nebular NGC 246 (which I'll post in the other thread) and just to get an idea of magnitude reach, a Shakhbazian group (SHK 265). What it demonstrated to me (yet again) is that observing using EEVA techniques can take place on any clear night regardless of the moon (though for those with an artistic bent perhaps lunar sketching makes more sense...) Martin

Here's Arp 200 from last night. I was mainly testing out the new cam and also interested to see how much effect the moon would have. I don't normally observe galaxies with a bright moon in the same quadrant but clear nights have been few and far between recently. This comes under the 'material ejected from nuclei' category in Arp's catalogue. I can't quite see what material is being referred to myself. I see a couple of bright spiral arms, with knots, plus a faint halo. I assume the other arms are out of view as the galaxy has an estimated inclination of 77 degrees. Out of interest, the PGC galaxy next to the close pair is mag 16.2 and the annotated m19.2 quasar is borderline detectable, so certainly not a washout for galaxy observing, though some way from optimal. Martin

Very useful to see an example of a working setup. Martin

I might give them a go tonight in spite of the near-full moon (crazy, but intriguing to see what can be done, and clear nights are not too frequent here). Canis Ma/Mi, Monoceros and Puppis are some of my favourite regions. Actually, I did look at a couple of PNs last night, not too far from the moon, and was surprised yet again at what is possible. This is NGC 2022, an object I was inspired to look at by Callum/BAA as the 'PN of the Year'. I stretched it a little more than I normally would to bring out the outer shell. The bright inner shell ring has two bright spots diametrically-opposed, one slightly dimmer than the other. I did wonder if one was simply a background star seen thru the PN but Hubble images confirm that these are part of the shell. Other images show the 'ring' to be two slightly offset semi-circles. I'd like to revisit this with no moon to see how much difference it makes. I also looked at NGC 1535 in Eridanus, looking rather solitary in a sparse scattering of stars. This is a fascinating object to view, in some ways comparable with NGC 2022 in the sense of having a ring and shell, but somehow better-defined. The outer shell in particular is remarkably smooth with a fairly clear boundary. In high resolution pictures the halo is not quite so smooth but has a filamentary structure. The inner region shows plenty of detail too, like a cut lemon slice. I'm guessing in this case the stellar object visible in the outer shell is a background star. Martin

Welcome to SGL! This is a useful site for star colours in general: http://www.vendian.org/mncharity/dir3/starcolor/ It's also an interesting exercise to download a star catalogue (such as XHIP -- extended Hipparcos) which contains stellar types and plot them with their associated colours. Good luck with your project. Martin

Glad that works for you. The developer's (third party, not SX) only response was along the lines of 'it would be surprising if the problem had been in the code all these years' .... then radio silence.... I do wonder how many people are living with this issue unawares. In my case it was obvious as I use the Lodestar for EAA rather than guiding. Martin

Things were somewhat steadier this evening. This is live-combined RGB (no L as I didn't want to blow things out), roughly 36 x 500ms subs in each filter. E and F are now more easily seen. I'd like to get the proplyds (G to I in the link I posted) but I'd need much better seeing (once or twice a year here). I used region of interest to select the central third of the sensor and also used equal aspect ratio to square things off. In all this made the individual subs (about 0.5M each) very manageable in terms of reading/stacking.