Jump to content

Banner.jpg.b89429c566825f6ab32bcafbada449c9.jpg

vineyard

Members
  • Posts

    1,124
  • Joined

  • Last visited

Everything posted by vineyard

  1. Thanks all - much appreciated. Finally had a chance to open it up today, and yep the belt had slipped (see photo). Taking the belt off and turning the big pulley wheel, everything was smooth. On closer inspection, I don't think the two pulleys and the plastic idler (if thats what it is called) had been aligned properly whenever this was installed (I bought it pre-owned). So the RA belt was riding over the lower lip of the plastic idler, and over time I think that has warped the shape of the belt & hence it slipped off eventually. Certainly when you lay the belt flat you can see it is warped a bit (2nd photo). The DEC belt was still v fine & properly set. I corrected the alignment, & also managed to fiddle with the horizontal spacing to increase the tension enough for the RA to work, but it will only be a matter of time before the warped belt slips again (you could see it moving up and down the pulley depending on which way the pulley was rotating). So I'm going to order a spare belt (maybe also some new alt-az adjustment bolts as well if they are stocked!). Let's see how much this improves guiding 🤞🏾(btw I did also find the hyper tuning how-to-video from astrobloke on Youtube - that looks quite interesting, esp if it gives such a large RMS gain). Cheers & thanks again all!
  2. Hello, A lovely two nights (last night was particularly fine). Sadly around midnight, when I was switching targets - going from the Rosette to Tadpole - it became clear that while EKOS/INDI thought the mount was slewing somewhere, the actual mount was not doing that physically. I shut down for the night & reconfirmed the problem this morning. Basically the RA axis (ie the one around which the scope and the counterweight rotate - want to make sure I'm not making a silly error in labelling!) doesn't rotate. If I set the mount to go somewhere, the DEC axis rotates, the mount makes noises for the rotation of the RA axis (I can hear something moving inside it - it sounds almost like a flapping belt?) but the counterweights stay firmly pointing down. I'm guessing something snapped or wore down? On the guiding side as well, the RA was much more volatile than the DEC last couple of nights. So this failure of something on the RA rotation would be consistent with that. I'm going to open it up to have a look, but thought I would check if anyone had ever experienced anything like this before, and/or if they were any good resources to look at first? I know of the astro-baby one for a non-belted version. Is there something for belted HEQ5Pros, or is it not that dissimilar, or would I be doing something v silly by opening it up myself (I'm working on the basis that if the belted mod can be done retroactively at home, then checking it also ought to be possible)? Worst-case, if it all goes pear-shaped, any recommendations for folks who can fix it (or folks to avoid pls!)? Thank you - luckily managed to get some nice footage of Rosette & already have lots of data on Tadpole so not too big a loss - especially if this leads to an even better performing HEQ5Pro! Cheers, Vin
  3. Caught this with my guide cam last night when setting up (the bright star is Polaris) - looks like a meteor?
  4. Wow, how do you get a pond & the sky in the same FOV?😮😂
  5. I've put a microSD card in now, and that lets me rewind images and look at them. Haven't been able to figure out how to take time lapses yet (it needs access to your Photos on the phone, but that option doesn't show up in my Settings - need to figure that out). Anyway, here's 3 images from just after 0700 this morning. The night-vision was still on (I've set it to "Auto" so it toggles from colour night-vision to proper night-vision based on ambient light, & then back again in the morning) - I figure the night vision setting will be more sensitive. As usual only PP'd on the phone itself. If there was a way of writing a script that could do this transformation automatically, that'd be great!
  6. That first H-a image is v fine - all your H-a with this setup have v good, clear & precise lines👍🏾. Out of curiosity have you tried your Quark in an achromat of similar aperture/focal length. It would be interesting to see how much of the image quality is the Quark & how much the FC100DL!
  7. Thanks Dave @Gunshy that's really helpful. Yes will tinker away w different settings to see what happens (the save log functionality is also handy that way ). I just posted a re-do of my IC410 using GHS w star-reduction here - the prior version above that (using now-old workflow) in that thread is just embarrassingly bad in comparison. A v nice tool 👍🏾👍🏾🙏🏾
  8. I re-ran the data using the new GHS script that @mike1485 recently shared. Here it is (star-reduced). I much prefer this version - I could clearly have done a better job of protecting the brighter stars, but the smaller stars show much better (tightness & colour) as well as the structures within the nebulosity. The colour is also much nicer. GHS is v interesting!
  9. Thanks @mike1485 - yes sorry clumsy typing of me - I meant that the additional nuances that come from GHS were just from that (ie without adding any LHE icing on top). Will report back on Fireworks hopefully in next few days. (I'm going to try & see if PCC on an unstretched image of that also introduces more graininess in GHS vs running GHS on the straight data - does PCC in essence distort the initial data histogram a bit (?) and therefore GHS initial settings may then perhaps best be starting with different D & b - let's see, I guess that's the pt of experimentation ) Cheers
  10. Uh oh. Will report back if it does conk out 🤞🏾
  11. That video was v helpful - thank you. And I have to say so far I am really liking the GHS tool! Excellent. Went back to some data on IC410 Tadpoles & played around with it (but w/o any HT, Curves Transformation or LHE). And I m-u-c-h prefer what came out this way. Workflow was 4 main steps: 1. ABE then GHS a few times (using the sliders as per the video) to generate an image to pull out range masks & star masks 2. With those masks, went back to the ABE image for Deconvolution. And then GHS again a few times, tweaking the settings. 3. Went back to the deconvolved ABE & did Photometric Colour Calibration (PCC wouldn't work on the GHSed image - I guess b/c its stretched?). Then GHS a few times again. 4. Pixel Math of the output images from 2 & 3 - the PCC image alone was noisier but had a bit more colour in darker areas which I couldn't yet figure out how to coax from GHS alone. So just a smidgeon of Image 3 in this Pixel Math. I definitely prefer what came out via this than the first time I played w this data using now old-for-me techniques. Since there are more clouds ahead, will try & play w old Fireworks Galaxy data too. Thank you again for creating & sharing this tool - another great example of the astronomy community spirit! PS - StarXterminator doesn't work on my laptop (old) so it'd be v interesting to see what would happen in other images if you separate stars from nebulosity & then play separately w GHS on each & then recombine?
  12. Some other nights/evenings - either w more clouds &/or earlier in the evening so you can see the image under different conditions. These are just quick smartphone processed.
  13. I/m not sure if this should be in equipment review or not. Basically just a quick post - Santa sent me one of these dinky cameras. And I have been trying it outside the last few nights - mostly cloudy of course but a few clear patches. It's v user friendly. Seems weatherproof so far. And the app is a v convenient way of seeing what is going on. And capturing data - below are just some screenshots I captured on my iPhone. I've yet to put a microSD card in but when I do, I should be able to get it to take time lapses etc - will report back on those. I like it so far. Have always wanted an all-sky cam but have been deterred by the cost & faff of using an ASI camera, fish-eye lens, RPi, weatherproofing & then the software compiling etc. This makes it much easier & cheaper (<GBP50 all-in) - ok its not a fish-eye lens, but is still 130 degrees. Below are 2 pairs of images, the first is the unprocessed one so you can see what is shown by the night vision ON, and then w the PP that the phone itself offers. I reckon if Wyze could build in some PP functionality on the app so that the realtime views can be adjusted, that would be brilliant. Anyway, so far v happy with it - will tinker with a microSD card in, & also with connecting it to a weatherproof solar panel which will allow it to be placed at the top of the roof w/o having to worry about cabling. Wrt FOV, I can count at least 5 constellations in these images - Orion (behind the tree) & then moving up Taurus (Hyades & Pleiades), Auriga, Perseus & Cassiopeia? Will try & update the thread w any more images or reports along the way.
  14. That's v nice - wouldn't look out of place as an illustration in Dante's Inferno!
  15. Just to say have been playing around a bit & it looks v promising indeed. I ran ABE, then deconvolution & then MLT on an image and then cloned it. On one I tried GHS and then two HTs, on the clone just an HT. And the GHS version looks far better - more subtleties & nuance in nebular features, and also it looks like less graininess on the background. This could be v promising & become a staple of my normal workflow - thank you for sharing, will continue to experiment with it!
  16. Thanks @vlaiv. So theoretically could you use one algorithm for the background (eg: bilinear) & then extract stars. And use a different algorithm for the stars, extract those & then combine the best of both worlds? Sounds v faffy, but if that works, then could this be written as a scripted process. If Siril takes 1/4 of the time of APP then you could run those two different stacks & have the best of both & still be done way before APP. (I wonder if APP creators are aware of this difference in speed & can re-engineer the software - its got to be a competitive disadvantage for them?) Btw, are there any lectures or videos which explain the intuitive logic between these different stacking algorithms? My maths is too rusty to understand the algebra, but if there were any intuitive explanations, it would be nice to understand the rough logic of the different approaches & settings! Cheers & happy Christmas!
  17. Crikey @Ags - 12 hrs! Well I tried Siril last night. Downloaded the latest version & found a tutorial on the OSC processing script. Once I realised the directory structure I had to set up, moved the files across & pressed go. The image below is what came out (again just ABE & HT in PI, then 2x downsampled & PNG'd). There still seems more graininess (noise?) in the background vs APP (which returns the cleanest). But the stars are the best in the Siril image - less blocky than APP & much less blocky than DSS. The whole thing (193 lights) took c 1h22 or so. That's not quite a LFL comparison b/c (a) it wouldn't accept the calibration master files (said s/t about the channels not matching the lights) & so I had to load all the individual calibration files & so the 1h22 includes the time for stacking those as well, and (b) my virtual windows machine decided to auto-update at one stage so that ate up some resources until I shut that. An ideal scenario would be to combine the clean background of APP w the better stars of Siril. Would that be possible w changing Siril settings somehow (I just used the script). Also nice would be an ability to weed out individual lights in Siril (eg: while I use Blink in PI to weed out obviously bad lights, APP's workflow also allows further weeding once quality scores & shape coefficients are calculated). I guess I need to start learning a bit more about Siril's tweakability now. Or else bite the bullet on a Windows mini-PC (cheaper than a Mac mini) just for processing (after all EKOS can work on Windows 10 too...). Cheers & happy christmas everyone.
  18. Thanks all for the further feedback, much appreciated! Yes I fear its looking like new hardware I suspect. @dannybgoode I do have an old surplus-to-requirements HDready TV & so was indeed thinking about a MacMini - do you use one? @ollypenrice unfortunately AstroArt only seems to be Windows & I'm Mac-based (I guess I could use a virtual windows machine which is how I use DSS). @The Lazy Astronomer & @ONIKKINEN those look like so much faster speeds on SiriL - I will try that & see (btw the self-built PC idea runs into my mac restriction as well as me not being sufficiently hardware-literate). Anyway, I left the machine running today while I did other things, and tried 193 lights of 60s with both APP & DSS. Images below are ABE & HT from PI (no other processing done), 2x downsampled & saved as JPGs. The APP version is the first one, the DSS the second. APP took 4h7 (quite a bit faster than 22h for 444 lights!) but still quite slow - DSS whizzed through in 1h10 for th. There does seem a difference in image-quality between the two though - DSS has a bit more pop (?) but also more noise/granularity (if you just look in and near the nebula at the dark space/cloud areas, ie ignoring the untrimmed edges from the APP mosaic since DSS clipped those off automatically). So unless I can somehow get SiriL to work wonders, its probably looking like new hardware - joy 😕 Cheers, Vin
  19. A star-reduced version (can't run StarXterminator on my machine for some reason so this is via Morphological Selection in PI).
  20. Oh that's interesting @gilesco - I've never used one of those before. So it's like a VM - I'd have to upload all the data to the cloud, and also install APP/SiriL/DSS etc to the cloud machine <does APP allow that?> & then run the processing on that (ie, essentially use the much faster machines of AWS)? I've always thought of AWS as commercial pricing, didn't realise normal retail accounts could also use it.
  21. Thanks all. V helpful. Sorry I should have clarified I am already using an SSD external hard drive. @Martin Meredith I will keep Activity Monitor running next time I process. But while looking at those aspects I checked the CFG settings on my APP instal, and it was only using 4GB of my system RAM. I'm guessing that will be dragging performance so I have upped that to 15GB (the highest choice it gives). @Laurin Dave my old laptop only supports USB2 so I am probably constrained by that wrt the external SSD drive read/write but that is s/t to keep in mind when I eventually get round to upgrading the laptop (its so old that it can only handle High Sierra OS 10.13 - the newest PI features which need later OS can't run on it - so I know its only a matter of time when the poor thing says "enough") @vlaiv that's a task for if the conditions remain so poor over the holidays I initially started w SiriL but found it cumbersome to use (but that may be b/c that was the first processing software I evert tried so was completely new to these aspects). I switched to DSS & found that much more user-friendly, but then noticed it consistently gave weird edge artefacts compared to APP on the widefield images I was taking with a flattened Evoguide50 so I switched to APP. I stopped using PI v quickly for anything other than post-processing b/c it just guzzled memory & time. @drjolo yes I think I will start trying longer subs. I use guiding & my RMS is usually <1 (unless its windy and I've got the 1m+ physical length frac mounted), so I have been chewing over increasing exposure time. I currently use 125 gain b/c its just above the level where read noise steps down on an ASI294MCP, so I'm hoping that that gain is fine for longer subs too (else it'll increase read noise quite a bit if the graphs are accurate). 1hr for 400 subs of 16Mb each would be awesome! That's a v handy comparison table, thank you. Just eyeballing it, my machine is i5 w a much slower CPU (1.3GHz) & effectively APP was only using 4GB of RAM as per above so that would put it waaaay at the bottom of that table, which would explain 22h (!). I guess I can't do anything about the CPU speed for now, so will try with a subset of lights running 15GB of memory in APP & see how fast that does it. And then also try a like-for-like comparison w DSS & SiriL - will report back if I get the chance to do that. Thanks again for all your help - it's always worth asking on SGL - happy holidays all!
  22. Hello, Apologies if this has already been discussed before, I was wondering what might be ways of optimising processing. Basically, I recently got 8h+ of data on IC410 - 60s lights coming to 11GB of raw data. After discarding some dodgy frames, I still managed to get 7h24 of data (here) which took my (admittedly v old) laptop 22hrs in APP to process (w 140GB of working memory needed on the hard drive). I'm v glad I did it b/c its a far better image than an earlier 2.5h exploration - more data clearly make a difference. But I'd eventually (weather permitting) like to be able to get to 24-30h of data on a target. But that would probably make my machine keel over (88hrs of integration in APP?!). So what might be some good optimisations to go for? Some ideas below but I've no clue whether they're daft , or which one would be better or worse. 1. Integrate in batches & then register & integrate (or pixel math) the output of each batch-integration? 2. Switch to mono, take 5-7h w each filter and then integrate each of those - then register & integrate (or pixel math)? This is a bit like 1 but perhaps this would give more holistic information because of the different filters (as opposed to just 24-30h of the same OSC filter)? 3. Take longer lights (120s instead of 60s) effectively having the total GB? Although that would introduce blow-out risk on brighter stars/nebulosities etc so might make processing slightly trickier? 4. Get a faster machine (but how much faster would that make it - would it be multiples? My mac is 10y old w 16GB of 1333 MHz DDR3 memory & 2.4GHz Intel i5 processor) 5. Forget about 24-30h b/c it would be diminishing marginal returns after X hrs? What is X though? Any other angles I am missing? Thank you & stay safe all, Vin
  23. Hello, Here's 7h24 of IC 410 taken over 3 nights. 60s lights w a TV102iis x0.79reducer/flattener. ASI294MCPro at -10C, gain 125, offset16. APP then PI. I've included a clean up crop (just trimming the edges & downsampled for size - my spacing isn't right), then a closer crop around just the nebula & then a v close crop of a particular area where there seem to be nice clouds - perhaps even some pillars - of nebulosity which one day I may try and go back to with a deeper scope. Cheers
×
×
  • 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.