Jump to content

Narrowband

Martin Meredith

Members
  • Posts

    2,267
  • Joined

  • Last visited

Everything posted by Martin Meredith

  1. From the same discoverer, and about 0.3 degree due south of HJ 2668, this is HJ 1238 in Virgo, discovered in 1828 with a 10.0" separation. The entry refers to the right-hand pair, with a most-recent (2016) separation of 14.5". I don't have spectral types listed for these but they must be hotter than the HJ 2668 pair. Also in the field is a much closer pair which go under the name DOO 56, discovered (as a pair) in 1913 with a separation of 3.1", which had widened slightly to 3.6" by the most recent 2015 measurement. Again, I don't have spectral types for these. Possibly I ought to be using shorter exposures -- its all part of the learning experience! The WDS code for the foursome is 13403+0709
  2. By the way, I'm sure there are plenty of people who know a lot more about double stars and the WDS discoverer codes than I do, so please do add any relevant info or correct my mistakes. To kick off with, here's HJ 2668 in Bootes, almost straddling the border with Virgo. This was discovered (by John Herschel?) in 1830 with a separation of 4", and the most recent observation in WDS is from 2015 which found a 10.2" separation. I chose this in part due to the almost equal magnitudes (11.9, 12.1) but without knowing anything about the spectral types (which are not listed in the WDS entry -- this precedes my selection criterion).
  3. Over the last couple of evenings of clear skies but with an increasingly bright moon, I've taken to observing double stars using the camera/scope/laptop. This is definitely not the same as visual observing; part of my plan is to observe some of the fainter classes (L, T) that are outside the reach of all but the largest visual scopes. For the moment I'm finding it enjoyable and relaxing to choose potentially interesting candidates and watch the image coming in for examples of the different spectral classes. The first night I simply selected some interesting looking cases from the charts, but last night decided to do a bit of data mining in the Washington Double Star catalogue. My selection criterion was systems with both spectral types listed, and where the spectral types were different from each other in the main class (eg G0 vs F3 was included, but G0 vs G1 wasn't), with the goal of finding some interesting colour contrasts. For anyone using Jocular here's a data file with 3557 such pairs (just drop it into the catalogues subdirectory of your joculardata directory and it will be available on restart -- the object code in the DSO planner is 'DS'). doubles.csv In the next post I'll start to include some observations. Feel free to add any others! Martin
  4. The de Vaucouleurs Atlas describes it as "one of the most remarkable S0 galaxies in the sky" with a "very well defined inner disk zone flanked by a noticeably warped thicker disk". They cite a 1984 article by Wakamatsu & Hamabe that suggests that "the innermost hump represents the ends of a bar oriented at an intermediate angle to the line of sight" and that the very sharp edge that we see is an edge on view of a lens.
  5. Well, it wouldn't be the first time I've lost the plot... Anyway, last night with it being clear but accompanied by a bright moon overhead, and there being few open clusters on offer towards the south, I did check out some doubles (may post elsewhere) purely for their aesthetic value. But with Virgo so well-placed the call of the galaxies was too strong to ignore, and the highlight of the night for me in spite of the moon was NGC 4762 in Virgo. This is a member of VV 1573 but the way my ASI 290 sensor was oriented was such that the pair only just squeezed on to the sensor, so I focused more on NGC 4762. This is a perfectly edge-on galaxy and as such shows a clear core. Below is what I tend to think of as a 'colourised' capture: that is, I started off in luminance-only, then added some RGB at the end to capture the pale peachy glow of the "arms" and the brighter yellow core. Just as with my previous post, no one stretch shows it all, and there is much more to this galaxy than its clean-cut central region. Barely visible in the gamma-stretched image are very faint curved extensions to the central streak of light. These are better seen using a hyper stretch on a negative image: The reason I put "arms" in quotes above is that this version makes me wonder if what we're seeing in the gamma-stretched image is the core plus an extensive bar, with the spiral arms only showing up in the stretched form. At any rate, there is a clear asymmetry in the outer parts and what to me is a surprisingly abrupt cutoff between the linear bar(?) and the rest. Time for some reading I think... Martin
  6. Here's a quick snap of a pair of mag 7-ish yellow-orange stars (both have B-V colour indices of ~ 0.9) in Bootes, close to the border with Corona Borealis. Gliese 593 is also known as Otto Struve 298, a very close double (sep 1.2"). However, since this is the interesting galaxies thread, using a more aggressive stretch reveals the main point of the operation, a pair of NGC/IC galaxies, plus a third galaxy, the triplet curving gently through the stellar pair. Distance-wise, the stellar pair are both listed at 73 light years (so presumably not just an optical pairing), while IC 4563 and NGC 5966 are about 30000 times further out at around 215 million light years. The middle galaxy, mag 16.4, is nearly a billion light years away. Martin
  7. I missed these too. Here's my Arp 263 from a couple of years ago. BTW I've made use of a new feature that Steve (from Boulder) implemented in Jocular (thanks!), which is the ability to drag label positions. This will be in the next release. It really helps when there are a bunch of interesting galaxies in the field, as in this case with the CGCG catalogue members.
  8. I think this thread will be very useful to lots of people wondering what is possible with EEVA, and what are the best settings for various types of DSO. I definitely have evolved different settings for different DSO types e.g. I find something like a log stretch works well with globular clusters. I probably haven't seen all the M objects in EEVA-mode as I tend to visit them if they're close to some other object I'm looking for, or to check alignment (I hope Messier would have approved...). Only this year did I see M78 for the first time (glorious in colour). Martin
  9. Chromaticity already has a slight degree of 'timid' noise reduction in that the colour stretch is the corrected gamma whose low-intensity end is noise-reduced. Perhaps a slightly more vigorous form of NR is required for these channels. I recently expanded the range of binning options for chromaticity (was 1x1 and 2x2, now 3x3 and 4x4 are included, though for my pixels at least they tend to produce smearing artefacts). It might be worth trying out fractional colour binning and adding that control to the interface. Colour processing in an EEVA context (i.e. trying to minimise the amount of user-controlled processing) is a fascinating business. It turns out that the critical step is boosting the colour channels (so they can be appropriately integrated with the L) while preserving colour ratios.
  10. Did you try the 'reshuffle' realign process to handle any alignment issues with B subs? As you may know, this works in part by reordering subs so that the first one comes from the lowest transmissibility filter. This is done because I estimate the star detection parameters for the first sub and then apply these throughout, so if they are set to e.g. extract N stars on the first (B) subs, that is going to be plenty for the other (more transmissible) filters. I find it almost always resolves any alignment issues that are due to low numbers of stars -- except perhaps in the case of cloud-induced loss!
  11. I think we can still support manual sub rejection/reselection even in the case where individual subs are not stored in memory, as the key thing is to be able to add or remove a sub from the stack, and for linear combination this can be done without access to the individual subs that made up the stack, so long as we're talking about a mean stack. What would be more difficult to support is median or percentile clipping, so satellite removal etc might have to be sacrificed. (Even in this case it could be done by reading in fractions of each sub multiple times -- slow but produces a similar end result so long as alignment info is also stored). I'm actually interested in combining aperture photometry with known GAIA G magnitudes for the stars I use for plate-solving. They will provide the necessary reference magnitudes so in principle it ought to be possible to deliver magnitudes for other stars in the FOV.
  12. It will be interesting to see how you get on. It sounds like it could get quite complicated, since the QE varies with wavelength and the RGB filters are reasonably wide. I imagine you'd need to know the spectrum -- approximately, or at least the colour temperature -- of each star in order to refine the QE estimate, or perhaps the mean QE over the passband will suffice. There are also alternative approaches to G2V that make some assumptions about the average colour temps of stars in a typical FOV. I'm currently working on FWHM estimation so that I can use aperture photometry to better estimate the RGB responses for G2V stars. Berry and Burnell is a goldmine for this type of stuff. I'm following their approach (fig 8.5, p 257) but fitting a Moffat function to the star profile. At the very least this will provide an estimate of the seeing...
  13. Apropos of the luminosity/chromaticity distinction, I spotted in Bracken's Deep Sky Imaging Primer a mention of adding synthetic luminance (formed from a weighted sum of RGB) to the actual luminance, to decrease luminance noise even further. I ought to do this (I currently use synL when there is no real L). It sounds like using the same info twice but I guess it is ok. For the EEA context, to avoid going down the slope towards AP, I think it is necessary to do quite a bit of chromaticity manipulation automatically. For instance, colour gradients are (optionally) subtracted from each channel, but there is no option to control the degree of subtraction as there is with the luminosity control. Similarly I only provide a single colour stretch family (corrected gamma) rather than the various options available for luminosity. Still, I sometimes feel that there is room for more chromaticity control... I removed the blue-yellow and green-magenta oppositions that corrected the background as they didn't seem necessary -- the automated gradient removal seems to do the trick. Its all a bit lonely for chromaticity at present with just colour stretch and saturation 🙂 BTW I've started work on automatic detection of G2V stars and now need to compute the colour ratio corrections robustly. One difficulty is not having a good record (in all cases) of the altitude of the detected G2V star, which is necessary to build a decent map in order to allow G2V correction in cases where there is no G2V in the image (the majority of cases are like this).
  14. Hi Pat I no longer use SLL (it doesn't work on my Mac) but I believe that is the way it is being used, yes. So, SLL would be used for focus/alignment/framing, then the FITs for the main captures are deposited in the watched folder and all the rest is done in Jocular. There is also a watched mode in which the Jocular start/stop control (camera icon) is used to determine when to 'listen' for incoming FITs, but it is probably simpler just to leave it as free-running. Concerning the exposure time, SLL doesn't write exposure to the FITs, so (optionally) you can provide it by selecting the exposure on the Jocular interface (clicking on the exposure time just below the camera icon). You then need to alter the WatchedCamera exposure setting to 'from user'. zadig is a way to install/update USB drivers on windows. You can use it to install libusb, which is required by Jocular (on Windows) in order to use the Lodestar natively. If you're getting issues connecting to the Lodestar then feel free to PM me the log file you'll find in joculardata/logs so that I can confirm that it is indeed not finding the libusb driver -- it might be something else. Martin
  15. I've just uploaded a new version (0.5.6) to the Python package repository. Main changes/improvements: [speedup] star extraction is now significantly faster; this will be noticeable particularly for those using larger pixel count sensors, and anyone who is loading previous captures will benefit; the degree of speedup can be controlled using the binning option in the conf/aligner settings screen [speedup] denoising (formerly known as TNR) is significantly faster; the degree of speedup is selected by choosing the degree of binning on the conf/Monochrome settings panel [enhancement] sliders (e.g. white point) previously resulted in continuous display updates; for larger sensors this resulted in laggy behaviour. Thanks to Steve in Boulder, there is now the option to update only when the slider is released. This is achieved by double-clicking the relevant slider, and the behaviour persists until the slider is double-clicked again. There is also a configuration option on conf/View that allows all sliders (except zoom and annotate) to update on touch up by default (restarting Jocular is required for this to take effect) [GUI change] rather than toggling the display of information panels via the eyepiece ring, there is now a separate 'info' screen that is accessed via its own 'info' icon; this frees up space on the eyepiece ring and allows for future expansion of information panels (e.g. FITs info) [GUI change] the sliders that control sharpness, denoising, gradient removal and background have now been regrouped and renamed; the light touch noise reduction slider has also been moved and continues to be called 'nr' [enhancement] in addition to automatic blackpoint detection, there is now automatic whitepoint detection. This is less useful but may find some uses. Both black and whitepoint estimation are toggled using the 'est' buttons at the extremes of the white/black slider (note that the button for blackpoint detection was previously labelled 'auto') [enhancement] colour filters can now be binned 3x3 and 4x4 as well as 2x2 [enhancement] filter information is now externalised in file filter_properties.json in jocular/resources. This is to allow users with nonstandard filters to have them recognised by Jocular. FITs handling of filters has also been updated to include Oiii and Sii (thanks to Steve in Boulder). [GUI change] a few font sizes have been reduced to support those using smaller screens (note that most font sizes can be changed dynamically via the conf/Appearance settings panel). You can upgrade to the new version using pip install --upgrade jocular==0.5.6 Please note that the documentation available on the official website has not yet been updated to reflect these changes.
  16. Are you using Windows or a Mac? If Windows, you may need to install the appropriate USB driver using zadig. However, some users have reported problems using the Lodestar on Windows. I had brief access to Windows (the only kind of access I like 😅) in order to test it myself a while ago and it worked fine. The alternative is to use SLL to produce FITs and dump them to the watched folder. This is the way MikeJW and BillS use Jocular. Martin
  17. Going back through some recent captures I came across M77 in Cetus. This is how it looks on the 'normal' settings I use for LRGB captures (gamma stretch), showing an extremely bright core region within which it is hard to discern any structure (even on a single blue sub it is bright and stellar). The spiral arms show what appear to be star-forming region (blue), all bathed in the yellow glow of a halo? of stars But it turns out that the galaxy is much more extended than this. Switching to hyper stretch and applying some sharpening produces a result that is not 'pretty' but which reveals a clear outer structure with what look to be a pair of additional spiral arms but which could well be continuations of the ones visible in the above shot. Something I've started to explore is subtracting the responses of different filters. This is early days but here's an example of using the difference between the red and blue filter as the luminance component. There is no finesse to this at present, hence the horrible artefact on the bright star to the left, but the process does hint at a double structure of some kind at the core (again, this might be an artefact).
  18. Interesting sequence of images. I see some differences but that might be more due to the stretch, NR etc than to the estimated RGB values. I find gamma or asinh works best for colour. For bright objects (and bright regions of objects), the SNR is going to be reasonable to start with, so the RGB values that are estimated from even a single short sub in each of RGB might be close enough to their 'true' values to produce decent colour, with the detail provided by the luminosity data. For fainter regions the RGBs will be noisier, leading to less veridical colour rendition. I've noticed that for low surface brightness PNs the colour noise can be quite bad (and for many galaxies). You can probably observe this effect in open clusters, where the bright members need very little RGB while the fainter ones need more. By default in Jocular RGB channels are binned 2x2 to increase SNR -- perhaps I should introduce more extensive binning?
  19. I had a look at Andromeda's Parachute recently (i managed to see the upper bulge and just about get the lower member) and I believe Nytecam tried Einstein's Cross some year ago. A decent focal length and good seeing is essential. Martin
  20. What starlightlive did was map 3 narrowband channels to RGB in a flexible way. What I'm not sure about is what happens in LRGB when you have say L+Ha+Oiii? It would indeed be easy to map to RGB -- just not sure what is the right thing to do when one only has one or two narowband channels...
  21. There is (red). What I mean is that no 'palette' for multiple narrowband (ie no HOS/SHO/HOO etc). You end up with something like this, great if you like pink but I think it needs more consideration...
  22. At present, unless defined in the FITs header, the only narrowband supported in the watched folder is Ha, and the name has to start with 'ha' or end with '_ha' (in any mix of upper/lower case). I can (extremely easily) add support for the other channels, just that nobody has done anything with narrowband yet via the watched folder and I didn't notice their absence since the way I use it is via direct control....
  23. 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...
  24. 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!
  25. 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
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.