Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.



  • Content Count

  • Joined

  • Last visited

Community Reputation

82 Excellent


About jager945

Contact Methods

  • Website URL
  1. Honestly, something like a used RX 570 also offers very good value for money (though since it's an AMD offering, it will have no CUDA cores). A bit more expensive (as it's a general purpose GPU), but quite a bit more powerful for compute purposes. There are mining versions of these around as well.
  2. Wow, that's quite the difference! It seems your CPU is very much bottlenecking your system here. If it truly is 10 years old, then that would make it a 1st generation i5 on an LGA1156 socket. Depending on your system, an ultra-cheap upgrade would be an X3440 (or X3450, X3460 or X3470) and overclocking that (if motherboard allows). This should give you 4 cores, 8 threads at higher clockspeeds.
  3. You will probably find the difference is actually even more dramatic when comparing the 1.7 non-GPU and GPU versions like-for-like (both versions are included in the download). The 1.7 version, particularly in modules like Decon, uses defaults and settings that are more strenuous, precisely because we now have more grunt at our disposal. For example the amount of default iterations has been bumped up, while Tracking propagation is now fixed to the "During Regularization" setting (e.g. this setting has been removed and is always "on" in 1.7), which back and forward-propagates deconvolution's effects throughout the processing history for each iteration, rather than just once post-decon (which in itself is already unique). This is precisely why GPU acceleration is so exciting; it allows for even more sophisticated brute-force techniques to complete and be evaluated in near-realtime. And it puts "holy grails" like anisotropic deconvolution within reach! The GTX 1070 is an amazing card btw; nice find! The whole Pascal generation of cards is excellent really.
  4. Great to hear you were able to produce a good image so quickly! Most modules that require a star mask now show a prompt that can generate one for you. Did this not work well/reliably for you? This is (very) likely an artifact of your monitoring application. Your GPU is definitely 100% loaded when it is working on your dataset; As opposed to video rendering or gaming, GPU usage in image processing tends to happens in short, intense bursts; during most routines the CPU is still being used for a lot of things that GPUs are really bad at. Only tasks/stages that; can be parallelised are rather "dumb" in terms of logic (with few if-then-else branches) perform a lot of complex calculations AND process large amounts of data complete in milliseconds (up to a couple of seconds or so) ...are suitable for momentary GPU acceleration. As a result, during processing, you should see processing switch back and forth between CPU and GPU. If you have a utility that shows you temperatures and/or GPU workload, you should at the very least, see spikes in temperature and/or GPU usage. Depending on how your monitoring application measures GPU usage, however, these bursts may even be too short to register. During any GPU usage, however, the GPU is fully loaded up. Spikes may be averaged out over time by your monitoring application (with CPU intermittently doing its thing, leaving GPU momentarily unused), making it appear only partial usage is happening. That is, as you now hopefully understand, not the case! If your monitoring application can show maximum values (for Windows you can try GPU-Z or Afterburner), you will almost immediately register the GPU being maxed out. Hope this helps!
  5. Actually, most applications do not make use of multiple cards in your system (ST doesn't). That's because farming out different tasks to multiple cards is a headache and can cause significant overhead in itself (all cards need to receive their own copy of the "problem" to work on from the CPU). It may be worth investigating for some specific problems/algorithms, but generally, things don't scale that well across different cards.
  6. For anyone interested, this is currently a very cheap solution (~40 GBP) to get your hands on some pretty decent compute performance, if you are currently making do with an iGPU or older (or budget) GPU.
  7. It's worth noting that CUDA is an NVidia proprietary/only technology, so anything that specifically requires CUDA will not run on AMD cards. Writing and particularly optimizing for GPUs has been an incredibly interesting experience. Much of what you know about optimisation for general purpose computing does not apply, while new considerations come to the fore. Some things just don't work that well on GPUs (e.g. anything that relies heavily on logic or branching). E.g. a simple general purpose median filter shows disappointing performance (some special cases not withstanding), whereas complex noise evolution estimation throughout a processing chain flies! I was particularly blown away with how incredibly fast deconvolution becomes when using the GPU; convolution and regularisation thereof is where GPUs undeniably shine. My jaw dropped when I saw previews update in real-time on a 2080 Super Mobile! I don't think APP uses the GPU for offloading arithmetic yet by the way. Full GPU acceleration for AP is all still rather new. GPU proliferation (whether discrete or integrated in the CPU) has just about become mainstream and mature. Hence giving it another look for StarTools. Exciting times ahead!
  8. "Por qué no los dos?" Have you thought of using the Optolong L-eXtreme as luminance and using the full spectrum dataset for the colours? Assuming the datasets are aligned against each other, it should be as simple as loading them up in the Compose module (L=Optolong, R, G and B = full spectrum) and setting "Luminance, Color" to "L, RGB" and processing as normal. It should yield the detail of the second image (and reduced stellar profiles), while retaining visual spectrum colouring. Lovely images as-is!
  9. Hi, Crop away the stacking artifacts around the edges and fix your flats (these are almost definitely dust donuts). If you cannot (or don't want to) fix the flats, mask out the dust specks before running Wipe. Have a look at the Wipe documentation here which incidentally shows examples of the same issue you are experiencing above. Hope this helps!
  10. Hi, I replied on the StarTools forum, but thought I'd post the answere here as well; This is a separate thing and doesn't have much to do with AutoDev. Wipe operates on the linear data. It uses an exaggerated AutoDev (e.g. completely ignoring your old stretch) stretch of the linear data to help you visualise any remaining issues. After running Wipe, you will need to re-stretch your dataset. That is because the previous stretch is pretty much guaranteed to be no longer be valid/desirable. That is because gradients have been removed and now no longer take up precious dynamic range. Dynamic range can now be allocated much more effectively to show detail, instead of artifacts and gradients. As a matter of fact, as of version 1.5, you are forced to re-stretch your image; when you close Wipe in 1.5+, it will revert back to the wiped, linear state, ready for re-stretch. Before 1.5 it would try to reconstruct the previous stretch, but - cool as that was - it really needs your human input again, as the visible detail will have changed dramatically. You can actually see a progression by gradually making your RoI larger or smaller; as you make your RoI smaller you will notice the stretch being optimised for the area inside your RoI. E.g. detail inside the RoI wil become much more easy to discern. Conversely, detail outside the RoI will (probably) become less easy to discern. Changing the RoI gradually should make it clear what AutoDev is doing; Confining the RoI progressively to the core of the galaxy, the stretch becomes more and more optimised for the core and less and less for the outer rim. (side note, I'd probably go for something in between the second and third image ) E.g. AutoDev is constantly trying to detect detail inside the RoI (specifically figuring out how neighbouring pixels contrast with each other), and figure out what histogram stretch allocates dynamic range to that detail in the most optimal way. "Optimal" being, showing as much detail as possible. TL;DR In AutoDev, you're controlling an impartial and objective detail detector, rather than a subjective and hard to control (especially in the highlights) bezier/spline curve. Having something impartial and objective is very valuable, as it allows you to much better set up a "neutral" image that you can build on with local detail-enhancing tools in your arsenal (e.g. Sharp, HDR, Contrast, Decon, etc.); Notice how the over-exposed highlights do not bloat *at all*. The cores stay in their place and do not "bleed" into the neighboring pixels. This is much harder to achieve with other tools; star bloat is unfortunately still extremely common. It should be noted that noise grain from your noise floor can be misconstrued by the detail detector as detail. Bumping up the 'Ignore Fine Detail <' parameter should counter that though. I hope the above helps some, but if you'd like to post a dataset you're having trouble with, perhaps we can give you some more specific advice?
  11. Hi, Stacking artifacts a clear as day in the image you posted (as is Wipe's signature reaction to their presence). Crop them away and you should be good!
  12. I sincerely hope you will re-read my post. It was made in good faith and answers many of your questions and concerns directly or through concise information behind the links. To recap my post; a great deal of your issues can likely be alleviated by flats, by dithering (giving your camera a slight push perpendicular to the tracking direction between every x frames will do) and using a rejection method in your stacker. If that is not something that you wish to do or research, then that is, of course, entirely your prerogative. Given your post above, it's probably not productive I engage with you any further at this time.
  13. Hi, I would highly recommend doing as suggested in step 1 of the quick start tutorial, which is perusing the "starting with a good dataset" section. Apologies in advance, as I'm about to give some tough love.... Your dataset is not really usable in its current state. Anything you would learn trying to process it will likely not be very useful or replicable for the next dataset. There are three important parts of astrophotography that need to work in unison. These three things are acquisition, pre-processing, and post-processing. Each step is dependent on the other in that sequence. Bad acquisition will lead to issues during pre-processing and post-processing. You can try to learn these three things all at once, very slowly, or use a divide and conquer strategy. If you want to learn post-processing now, try using a publicly available dataset. You will then know what an ok (not perfect) dataset looks like and how easy it really is to establish a quick, replicable workflow. If you want to learn pre-processing, also try using a publicly available dataset (made up out of its constituent sub frames). You will then know what settings to use (per step 1 in the quick start tutorial, see here for DSS-specific settings) and what flats and bias frames do. Again, you will quickly settle on a quick, replicable workflow. Finally, getting your acquisition down pat is a prerequisite for succeeding in the two subsequent stages if you wish to use your own data; at a minimum take flats (they are not optional!), dither unless you absolutely can't, and get to know your gear and its idiosyncrasies (have you got the optimal ISO setting?). The best advice I can give you right now, is to spend some time researching how to produce a clean dataset (not deep - just clean!). Or, if you just love post-processing, grab some datasets from someone else and hone your skill in that area. It's just a matter of changing tack and focusing on the right things. You may well find you will progress much quicker. I'm sorry for, perhaps, being somewhat blunt, but I just want to make sure you get great enjoyment out of our wonderful hobby and not endless frustration. Wishing you clear skies and good health! EDIT: I processed it, just to show there is at least a star field in there, but, per the above advice, giving you the workflow would just teach you how to work around dataset-specific, easily avoidable issues...
  14. Glad I could help! With regards to the spiral arms, it depends on your dataset. If you'd like to upload it somewhere I'd be happy to have a look. For images like these, the HDR module's Reveal All mode may help, as well as the Sharp module from ST 1.6 (DSO Dark preset, overdrive the strength). You'd use these tools specifically as they govern small-medium scale detail. It's also possible a different global stretch (with a Region of Interest in AutoDev) can lift some more detail from the murk. Much depends on your "murk" (e.g. how clean and well-calibrated the background is) as well
  15. Nice going! The star halos are likely caused by chromatic aberration. You can use the Filter module in StarTools to kill those fringes; create a star mask with the offending stars in it, then, back in the module, set Filter Mode to Fringe Killer. Now click on different halos and different parts of the halos (e.g. not the star cores, but the halos themselves!) until they have all but disappeared. You'll end up with white-ish stars for the stars that were affected, but many prefer this over the fringes. Finally, if you are suffering from colour blindness, be sure to make use of the MaxRGB mode in the Color module. It should allow you to check your colouring and colour balance to a good degree, as long as you can distinguish the brightness of the 3 maxima ok (most people can). See here for more info on how to use it. Clear skies!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.