Jump to content

sgl_imaging_challenge_2021_2.thumb.jpg.72789c04780d7659f5b63ea05534a956.jpg

M101 and Startools 1.7 Alpha, a first look


Recommended Posts

I have always been interested in Startools. It has a very distinct philosphy of how to process astro images. I have a license since version 1.3 (many years ago), but have never been in love with the product. At the time I was imaging with a 50 megapixel dslr and that was way too much for the processor hog that Startools is. It does a lot of computational analyses and it just froze.

Now, with version 1.7 (Alpha at the moment), there is GPU support. I have a decent GPU (GTX1070) for video editing and I decided to give it another look. I am proficient in Photoshop; am somewhat intermediate in PixInsight. I had to start from zero with Startools. I must say that I am very impressed. I gave it an image from my QHY168C, taken last spring. After one or two video tutorials and a read through the forums, I was on my way. It is very easy to get a decent image out of it, even using all the defaults. Just follow the course of the tabs on the left hand side and there it is. Of course that does not give the optimum result but 80% I would say. The hardest part for me was to generate good star masks where needed (that is the same issue in PixInsight). 

Attached is the result after two tries using Startools alone. Most of the processing time is waiting for the computer to do its magic (GPU support helps, but I measured utilisations between 6 and 10% so there is room for more speed). I am sure that with time and more experience I can get better images out of Startools, but for now, I took the RGB image, developed the Ha image in Startools as well, generated a starless Ha version with Starnet++ (from within PI and configured for GPU support) and also generated a starmask in Starnet++ from the RGB image for use later on. 

I took all of that, loaded the images and masks into Photoshop and did a layer combination of RGB and Ha and some color and contrast tweaks (pure subjective and to my liking).

You can find the final (Startools+ Photoshop) result and the acquisition details here: https://www.astrobin.com/6mnkki/0/

I will continue to use AstroPixelProcessor for stacking, PixInsight and Photoshop for post production, but will certainly dive deeper into Startools. It is a great tool to have in the kit. And..for beginners it is a really good way to start. Defaults work out of the box and you can tweak a lot of parameters when the experience grows.

M101-startools.jpg

Edited by Annehouw
  • Like 6
Link to post
Share on other sites

That’s an excellent M101. I totally agree with your assessment of Startools, it’s quite straightforward to get a decent result, but more in depth work is required (like all image processing) to get that other 20%.

I’ve just upgraded my Processing PC which now includes a GPU, and look forward to trying out version 1.7.

Link to post
Share on other sites

Great to hear you were able to produce a good image so quickly!

Quote

The hardest part for me was to generate good star masks where needed

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?

Quote

GPU support helps, but I measured utilisations between 6 and 10% so there is room for more speed

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!

Edited by jager945
  • Like 2
Link to post
Share on other sites

Hello Ivo,

Nice of you to comment from down under! 

 

I do not know if a full discussion on the internals of Startools is appropriate here or better on the Startools forum. I have not posted my comments there. What I see can still be novice user error. The main takeaway here was that I was impressed with Startools.

Having said that:

 

GPU support

First of all: other software developers have promised GPU support for some time; you are delivering. I am aware that it is not a trivial undertaking. So hats of for that! 

Having measured non-GPU-assisted Starnet++ and GPU-assisted Starnet++, I measured (in windows task manager) a full load for 25 seconds before completing the task. And that made me very happy because that is 5x speed increase. 

Now, I do not know the internals of Starnet++ processing or Startools, so like you say it might just be the nature of the computation that makes this so.

Anyway, I did measure a deconvolution in Startools (1.7.422 alpha), but now a bit more precisely using Gen-Z.  I have attached a screenshot and as you mentioned, there are indeed 100% utilisation spikes with 30-40% bumps as well (disregard the 1% number, this is just the value at a later time of screen capture). 

 

Star masks

I did use the automated starmask generation when prompted, but I also used a starmask using the "stars" and "fat stars" options with old mask set to "add new to old". This renders decent starmasks. Tinkering with that (growing a few times and then shrinking) did produce square dots however. I think this is just my lack of onderstanding how to manipulate the mask feature. But there is more (and that is not limited to Startools): My stars have spikes and halos. This is because of a 3 element Wynne corrector in front of the sensor, filters and less than perfect AR coating on sensor and camera. See the attached image. As a result most of my stars look fattish and star control is one of my most difficult challenges. Startool masks (and PI masks for that matter) generate round stars. The best way to date for me is to do a rather convoluted round of processing:

- (Auto) Develop the image using a ROI to get somewhat contrasty stars.

- Use Starnet++ to generate a starless image. This is never 100% correct because Starnet++ was not trained on my type of star shapes and a lot of brighter stars and their halos remain partially in the "starless" image.  Sometimes this looks rather ugly.

-In Photoshop: Remove the remaining partial stars, halos and other artefacts  from the "starless" image by using healing/cloning and such. 

-Subtract that image from the original image (can be done in Photoshop as well) to get a fairly accurate star mask representative of my actual star shapes.

- Curves or levels to tighten the starmask if needed

- Bring that mask into Startools (or any other imaging processor)

So, this is highly specific to my situation and most people most probably can get by with automatically generated star masks. I have not found the holy grail yet. In my experience, star control has a lot of impact on the appearance of the image. It just looks a lot cleaner. I did use the shrink tool in Startools btw and that works fine. Having a really accurate star mask for me remains to be key. But that is just my personal opinion in trying to get the most of what I spent 20+ hours to image (in a cloudy climate). 

I hope this clarifies my "starmask" remark.

 


 Met vriendelijke groeten,

Anne

 

 

GPU load.JPG

haloandspikes.JPG

Edited by Annehouw
Link to post
Share on other sites

It is probably a good idea to forgo the GPU utilisation discussion and look at what it means in practice. To that end, I loaded this image (4851 x 3044 pixels) and measured two actions with a stopwatch:

Startools 1.6 ( CPU only: 10 years old Intel i5 ) Autodev (with ROI):  13 seconds. Deconvolution (PSF Moffat Beta=4,765, radius=2px, 7 iterations, rest default) 132 seconds

Startools 1.7 (CPU i5 + GPU: NVidia GTX1070) Autodev (with ROI): 3 seconds. Deconvolution (same settings as above, rest default) 39 seconds

So on my system 1.7 is 3 to 4 times faster than 1.6.  Really Impressive.

 

P.S: I bought my video card second hand from a crypto miner after the crypto-mining rush was well over its peak, so I got a good deal on it. 

  • Like 1
Link to post
Share on other sites
15 hours ago, Annehouw said:

It is probably a good idea to forgo the GPU utilisation discussion and look at what it means in practice. To that end, I loaded this image (4851 x 3044 pixels) and measured two actions with a stopwatch:

Startools 1.6 ( CPU only: 10 years old Intel i5 ) Autodev (with ROI):  13 seconds. Deconvolution (PSF Moffat Beta=4,765, radius=2px, 7 iterations, rest default) 132 seconds

Startools 1.7 (CPU i5 + GPU: NVidia GTX1070) Autodev (with ROI): 3 seconds. Deconvolution (same settings as above, rest default) 39 seconds

So on my system 1.7 is 3 to 4 times faster than 1.6.  Really Impressive.

 

P.S: I bought my video card second hand from a crypto miner after the crypto-mining rush was well over its peak, so I got a good deal on it. 

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.

Link to post
Share on other sites

I couldn't resist and did the comparison, but had to bin the image 50% to keep my sanity.

So now, on a 2420x1520 image:

  • Startools 1.7 non-GPU.:     Deconvolution default settings: 165 seconds
  • Startools 1.7 GPU edition: Deconvolution default settings 15 seconds

 That is a massive 11 fold speed increase.

  • Like 1
Link to post
Share on other sites
On 07/10/2020 at 20:48, Annehouw said:

I couldn't resist and did the comparison, but had to bin the image 50% to keep my sanity.

So now, on a 2420x1520 image:

  • Startools 1.7 non-GPU.:     Deconvolution default settings: 165 seconds
  • Startools 1.7 GPU edition: Deconvolution default settings 15 seconds

 That is a massive 11 fold speed increase.

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.

 

Link to post
Share on other sites

Thanks for the suggestion, Ivo

Actually it is LGA1155 (with i5-2500K). I had never thought about upgrading it with a Xeon processor. Since Moore's law stalled I have not really looked into speed, aside from SSD and extra memory.

It is my professional production machine and runs very stable, so not so inclined to tinker with it.

Recent developments (as in Zen3 today) might however persuade me to plan a motherboard/CPU/memory upgrade at some time in the near future. 

 

Edited by Annehouw
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • 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.