Martin Meredith

There currently is no palette ie no HSO/SHO etc. It isn't yet implemented. I need to think about the best way to do this. The only thing that is implemented is L + narrowband, but that is a single narrowband, not multiple ie no L+ha+oiii Something to add to the to do list...

I also looked at this one a while back. It isn't as clear as in mono but NGC 4302 does show some interesting reddening in the central region. Thanks for the link Bill -- I'll check to see if any of this colour is meaningful!

Hi Pat Feel free to PM me if you come across any specific issues. Once you get Jocular running you'll find the logs in the joculardata directory and these are most useful for me to spot any problems. Good luck Martin

Good luck with googling x box galaxy... I've come across box galaxies a couple of times. I forget what they signify exactly but the X refers to the shape made by the central region, as in NGC 128 (part of VV894)

Though I wonder what the confidence intervals are on those distances? They seem close enough for the system to be interacting, and there does appear to be a faint bridge between the two, but that might just be wishful thinking...

Nice -- One of the clearest images (EEVA-style) that I've seen of the bridge, and great to see it in a wider context. BTW Arp 104 is where this thread started so I hope that doesn't mean we're done with the complete catalogue 🙂 Martin

Nice work Bill. I hope these are still around when I next get to my scope in a few week's time. NGC 3367 is a beautiful galaxy in its own right -- good old supernova leading you there! Martin

Yes, a wonderful pairing (spot the Hickson)

An issue Mike ran into using the latest version of Jocular with StarlightLive (SLL) is that the latest release of the package I'm using for reading FITs (astropy) doesn't like SLL FITs files (this is a known issue and will no doubt be fixed in the next release of astropy). The solution is to downgrade to the previous release of astropy immediately after installing Jocular, by typing: pip install -U astropy==4.2 I'll ensure that the next Jocular release only depends on v4.2 of astropy if the issue isn't fixed before then.

You could look it up on Simbad: http://simbad.u-strasbg.fr/simbad/ The approach I sometimes use is via Aladin: https://aladin.cds.unistra.fr/AladinLite/; enter NGC 5371, click the Simbad checkbox, check out the designation of the MAC object, and enter that into Simbad to see more information.

Hi Pat Its a while since I used SLL but are you using the linear stretch function here or the X^0.25 or asinh? From your captures I would hazard a guess that you are using linear? I generally found one of the nonlinear stretch functions did a better job of not blowing out the cores of galaxies/clusters. I was also in Canes Venatici last night but with my 77mm refractor and eyepiece. M51 was a couple of fuzzy blobs, one perhaps slightly larger than the other... Martin

Done! The version is 0.5.5 I've incorporated Tony's suggestion to reset the TNR and sharpness controls to 'off' at the start of each new object.

I should add that my original noise reduction slider (labelled 'nr') is still present. This has a slightly different and more modest purpose when compared to TNR. All it does is smooth out the very low end of the intensity range (and as such doesn't produce artefacts). The rationale is that some of the more powerful stretch functions tend to behave badly for very low intensities (often having gradients tending to infinity), so extremely low level noise is amplified. The 'nr' slider attenuates low intensity levels in a smooth way. I tend to have it on max so there may be a case for removing this slider and allowing any user that prefers something other than max to set it on a configuration panel. My only concern is not to remove any genuine faint stuff. However, moving the 'bg' (background) slider to let in more background (which might actually occasionally contain 'target' faint stuff) can have a similar effect as backing off the noise suppression.

BTW Note how Tony's noise reduction also deals with the dust bunny! Small sensor people perhaps no longer need flats...

I don't have such a large FOV but here's the same processing applied to Arp 16 (ie, 2 of the galaxies in Tony's shot) No processing Sharpening (about 60% of the way) Sharpening plus TNR (about 70% of the way) Monochrome: that's all the monochromatic processing; there's also Multispectral (LAB Colour on the config screen) which handles all the colour/narrowband stuff.

Prior to incorporating it in a normal release, there's a dev version that can be installed with pip install jocular==0.5.4.dev5 which contains a couple of new sliders 'sharp' -- unsharp masking 'tnr' -- 'Tony's Noise Reduction' (based on an algorithm developed by AKB -- thanks!) Both have parameters that can be set under conf/monochrome for altering things like radii/kernel size. Both are switched off at the '-' end of the slider. Note that if you choose a large value for the radius or kernel size the algorithm can be quite slow (but I find it usable for up to 2M pixels). Feel free to have a play. I'll document them properly in the upcoming release (and most likely shift the sliders around a bit) Here's an example of sharpening a recent Messier 88 (7m15s in 15s subs; Lodestar X2 mono + filters, LRGB) The dev version also fixes a few bugs and reads the temperature directly from the sensor if you're using an ASI camera. Any comments/examples of the sharpening/noise reduction welcome as I'm happy to incorporate any changes before the official release.

Good idea.

That'll be me, posting software updates 😀. Do these images benefit from your new noise reduction algorithm and/or sharpening? Impressive as ever to see these objects in a wider field. Martin

Time Machines by Paul Nahin is a great book for exploring some of these issues

Yes. The names should start with 'red', 'green', 'blue' or 'ha', or end with '_red', '_green', etc (the rest are treated as lights). There are some special cases for programs like StarlightLive that append various prefixes such as 'image_' e.g. 'image_red...' However, if the information is available in the FITS header that will be used instead. In this latter case the FITS keyword is 'FILTER' or 'FILT' and the value can be in various forms, including 'r', 'R', 'red'. It is easy to add more if other programs use different conventions.

Hi Tony Ugh... of course, this shouldn't be happening. Pending a deeper look here's what I think is going on: since implementing ROI, when looking for appropriate calibration frames I no longer enforce a match in image dimensions but instead use a match in the 'camera' property (and check that the light is a subregion of the calib frame). However, the camera property is only set for ASI cams at present, so as a fallback I do allow matches for cameras (such as the Ultrastar) where the camera property is not set. Let me think about a fix... Could you say more about the platesolving issue? Do you think the FOV is too large or too small? Have you retired the poor Ultrastar? Martin

Very clean and deep results for single subs. Seeing doesn't look that bad 😀 Have you tried stacking shorter subs to get the near-live experience? Martin

Yes, this is a Kivy issue but those steps (thanks Victor & Fozzy!) or something like them ought to work. I've had it running on a RPi. It is rather slow on the Pi though and isn't really recommended, at least for larger pixel count sensors. Martin

Excellent images of Arp 1. No idea why I've not looked at this (except in my case the scope is much easier to set up facing south...). Posting the image from the 200" is a good idea -- let's see how much we can tease out.

Great to see a spate of new Arp postings. Looking thru some of mine of the recent ones, here's Arp 243 with the Lodestar from 2019 on a decent night, although at 30s I was getting some trailing in alt-az mode. There's a lot of structure in the 'interaction zone' here.