M101 HDR processing: StarTools vs PixInsight.

[Geoff]

I happened to stumble upon this while doing a bit of idle web surfing.

http://startools.org/drupal/node/31

Someone from the PixInsight team might like to comment.
Geoff

[Flea77]

I saw that the other day, the increase in detail is impressive in the one they did, but, and I am no expert at all, doesn't the increase in contrast in theirs look like they just clipped the blacks and lost a lot of nice faint fuzzy in the process?

Allan

[vicent_peris]

Hi,

IMHO, this "article" is not very informative nor oriented to teach us anything, as it only shows one image at the end. Moreover, their result has strong large scale ringing artifacts (although it has managed very well the small-scale, bright structures inside the galaxy).

The goal of my article was to show how can we get decent result with a simple and quick workflow. The goal of this article is to show how you can get better(?) results than PixInsight in just a few clicks. It would be smarter to teach a more complex workflow, as the one I showed in a recent article here. Great, they are doing better than an article published two years and a half ago...

Honestly, I do think that every article in this website teaches something interesting. That's what they are written for.


Best regards,
Vicent.

[Carlos Milovic]

I welcome a little competition It has been too quiet around
Thanks Geoff for pointing that software. I have seeing their descriptions, and there is pretty interesting stuff. Despite the fact that I don't agree with such "black box", almost fully automatic approach (for several reasons), they are doing some very good things, like the correction of stars due coma. On the other side, they should take more care in the artefacts they are generating by the different algorithms (for example, see the ringing in the deconvolution). Sometimes doing things fast, and so automatically, do not yield close to ideal results (they may be the optimal result, from their automated search).

Anyway, I'm glad that there is somebody else trying modern techniques, and pushing the line a bit forward. Our goal here is to provide with powerful and flexible tools to achieve the best results. So, this is a motivation to do things even better, and keep the development of new tools going.

[Juan Conejero]

Vicent, excuse me but you wrote that article in 2007... so it is more than five years old now

The dates shown on our website as 'last updated' at the bottom of each page refer to the dates we uploaded new contents for each document, not to their publishing dates. In this case your article was last uploaded (without contents modification) in 2010 as part of a server migration, but we first published it back in 2007.

I never publish direct comparisons with other software products. That is not an elegant practice in my opinion, and definitely is not my style. In his article, Vicent presents a new image processing algorithm---it was new in 2007---that he had created, and its implementation as a PixInsight tool. He puts a practical example and describes some processing steps, including the reasons to apply each step and the different problems being solved. I don't think that the result that has been shown in this comparison is better than Vicent's 2007 result. On the other hand, Vicent's article was not written to show a nice result or a nicely finished picture; it was written just to be useful as a description of some new techniques and their implementations. Taking the final image of this article as a starting point to develop a software-to-software comparison is surprising to say the least. Finally, if somebody wants to know the current (publicly available) state of our high dynamic range algorithms and techniques, take a look at this article.

I have made a quick (and dirty) test with the same Jim Misti's M101 image, just to show that a slightly more careful procedure can yield better and nicer results very easily in PixInsight. Of course, PixInsight is all about having full control on the applied processes and a full understanding of the data, so this is not "just a few clicks". For black boxes and magical solutions, there are plenty alternatives out there.

This is the cropped and stretched original image (STF AutoStretch parameters applied through HistogramTransformation):

Click to see full size image

and here is the result:

Click to see full size image

To reproduce my processing, follow these steps:

1. Open the original image by entering this command on the Process Console window:

open http://www.mistisoftware.com/astronomy/fits/m101_050511_12i60m_L.FIT

2. Load the following XPSM file with this command:

open http://pixinsight.org/images/forum/20120710/M101-HDR/M101-HDR.xpsm

Now you have six icons on your first workspace.

3. Drag and drop the 'initial_crop_and_stretch' icon to the image.

4. Drop the 'star_repair_mask' icon on the M101 image. This generates a simple mask that we'll use later in step 9. Select the M101 image again.

5. Drop the 'HDR' icon on the M101 image.

6. Make a duplicate of the image (after applying the HDR icon in the previous step). This is a mask that we'll use in the next step. Enable this mask by selecting the M101 image and Mask > Select Mask from the main menu (or, if you know PI's drag'n drop idioms, drag the mask's view selector to the image's view selector tray).

7. Drop the 'CLAHE' icon on the M101 image.

8. Remove the mask by selecting Mask > Remove Mask.

9. Drop the 'star_repair' icon on the M101 image.

10. Drop the 'final_stretch' icon on the M101 image.

Note that we are working with the full size image, not on a binned image. To inspect the contents of each icon, double click it. Some icons transport ProcessContainer instances, which group several processes as a single instance.

The result of the comparison made with the other software shows large-scale ringing artifacts. The most conspicuous one can be seen at the right side of M101, halfway from the center of the image. Note that this artifact is even darker than the mean sky background measured on the corners of the image. The second worst ringing artifact can be seen at eight o'clock, just at the edge of the galaxy. None of these artifacts are present in our results. Besides that, the result of my test solves the high dynamic range problem posed by this image completely down to the nucleus, which is show with stellar appearance, and has much better small-scale contrast on the central regions of the galaxy and on all small-scale structures in general.

On the positive side, the result of the other software has less star bloating problems. Anyway, as I have said before, this has been a quick test where I have made no effort at all to control these and other problems. I have no doubt that many PI users (perhaps with a bit more free time available than I have now, since I am in the middle of a new version release) can easily outperform my result.

If somebody is interested, I'll be glad to explain all the details of my processing, including the reasons for each step, the algorithms applied, the benefits and negative side effects of each algorithm and how we can try to minimize them.

[Geoff]

.I never publish direct comparisons with other software products. That is not an elegant practice in my opinion, and definitely is not my style. In his article, Vicent presents a new image processing algorithm---it was new in 2007---that he had created, and its implementation as a PixInsight tool. He puts a practical example and describes some processing steps, including the reasons to apply each step and the different problems being solved. I don't think that the result that has been shown in this comparison is better than Vicent's 2007 result. On the other hand, Vicent's article was not written to show a nice result or a nicely finished picture; it was written just to be useful as a description of some new techniques and their implementations. Taking the final image of this article as a starting point to develop a software-to-software comparison is surprising to say the least. Finally, if somebody wants to know the current (publicly available) state of our high dynamic range algorithms and techniques, take a look at this article.

I agree wholeheartedly. I found the StarTools vs PixInsight quite annoying when I accidentally came across it--especially the fact that there was a bald conclusion that one was better than the other without even showing the PI picture or providing a decent reference to it.
Geoff

[DanielF]

If somebody is interested, I'll be glad to explain all the details of my processing, including the reasons for each step, the algorithms applied, the benefits and negative side effects of each algorithm and how we can try to minimize them.

I would be very interested to learn more about that if you would like to explain what you mentioned above.

/Daniel

[GrahamJC]

I would also be very interested in the thought process behind each step. The fact that PI makes details of each step explicit and does not rely on magic techniques was what attracted me to it in the first place. I am still on the lower slopes of the learning curve and all information on the hows and whys of processing using PI are very gratefully received.

Graham

[mschuster]

Thanks Juan for your post. Having data and icons to play with is very helpful. New feature request: Add "Amount:" as in CLAHE to HDRMT.

Thanks,
Mike

[cs_pixinsight]

This new software, while maybe going about the wrong way of gaining interest in it, has some very interesting features.  Some that I'm keenly interested in are:

• Correcting stars affected by tracking error
• Removing all the stars for non-star feature enhancments
• Coma correction

I'm aware of PI being able to remove the stars (although not as cleanly as I would like), but the the other two are something that have been asked about and would be terrific additions to PI.  I'll have to do some more due diligence on these features, but having ways to fix slight tracking error and especially coma would be nice tools in the tool chest.

Craig

[Carlos Milovic]

Hi Craig

The first issue can be adressed with a deconvolution. Yes, results are not that good right now. Fixing motion blur is a complex task, that requires a good stimation of the PSF, and the regularization parameters (as long with a carefully fine tunned deringing). I hope that the new TGV based regulazation that we'll develop these following months will yield better results.
Now, if the trailing was originated by field rotation, the problem becomes much harder. Traditional deconvolutions apply the same PSF to the whole image. A radially dependent PSF like this one may be fixed by transforming the image to polar coordinates (with the propper center).
Fixing coma is a much harder problem, from the deconvolution point of view. Now the PSF is totally spatially dependent. There are ways to bypass that, by dividing the image into several patches, and performing optimization routines inside of them. Also, how to model the optical flaws is a problem itself... I plan to do research on that topic, and develop a global strategy to deal with this, but I cannot give a timescale for a implementation.

This is what I would do... and what is the solution from an inverse problems point of view, that tries to correct all the data of the image, finding an optimal image that is the closes possible to the ideal one. There are also dirty trick that can do the job, for the objetcs that were most affected (start, mainly the brightest). And I suspect that they may be doing just that. The key here is segment the troublesome data (finding all the stars), and then perform, for example, morphological operators to achieve the desired result. Shrinking stars with a erosion filter is easy, and working on small windows will allow to follow changes in direction quite easily. Also you can do even trickier stuff like deleting the star, and replacing it with a gaussian model, that matches the flux of it and the mean fwhm.
Anyway, I would like to know which approach are they following... but since they use a "black box" policy, it may be difficult.

[Gary]

In my opinion half the fun of astronomy is in processing the images afterwards. Having as much controll as pixinsight gives me is what braught me to pixinsight in the first place.
If StarTools was half as good as its being made out to be then the developers shouldnt find the need to compare it to other software, thats just degrading there reputation imo.

Gary

[georg.viehoever]

I think the value proposition of StarTools ("StarTools automates, optimizes and enhances traditional image processing steps. Do away with tedious tasks and leave the guesswork to the CPU.") is quite attractive to a number of users. I have no idea if StarTools actually lives up to its claims, but it is certainly in stark contrast to what PI gives you.

My current favorite example is ImageIntegration: We have seen at least 20 messages in this forum from people that struggle with memory shortage. Still, we have not seen a move to simplify the settings in this area (Buffer and StackSize), for instance by providing reasonable defaults based on the detected free memory in the system. Problems like these -along with its incomplete documentation- make life difficult for new PI users. And they make such (supposed) push button solutions as StarTools attractive.

Georg

[Juan Conejero]

Hi Craig,

Correcting stars affected by tracking error

Solutions of the 'correct the stars' kind fall in the painting/retouching category. We are not interested in these. This is astrophotography, not artistic/general photography, and hence retouching tricks are excluded from the game.

As Carlos has pointed out, the only valid solutions to this problem are those that act on the whole image, including deconvolution and other global optimization techniques. There are different types of tracking errors; basically constant/linear errors, field rotation errors, and accidental tracking errors. Some of them can be treated, some cannot.

However, even if you can 'fix' wrongly tracked frames with deconvolution, the resulting data will always be poor data. No software solution can return a wrongly tracked image to the state it would have if acquired with perfect tracking because we are dealing with discrete, noisy and band-limited signals.

So the only solution to tracking problems is fixing the hardware that is causing them: throw away all wrongly tracked frames, look for the causes of bad tracking in your equipment, analyze and understand them, and fix them. Then acquire the data again. Astrophotography requires the pursuit of excellence, both technically and aesthetically. No software 'magical box' can help you to achieve that.

Removing all the stars for non-star feature enhancments

Stars and other jump discontinuities can be seen as singularities in a digital image: A star is a place where many of the algorithms we use to model and transform the data cannot be applied. For example, all algorithms involving high-pass filtering based on convolutions tend to generate ringing problems around stars and high-contrast edges. We have developed star masking techniques and deringing algorithms to solve these problems.

Again, 'removing all the stars' does not seem a serious starting point to develop robust and efficient techniques to deal with ringing problems. Just to name one of the conceptual problems behind the 'remove all the stars' idea, you cannot remove all the stars without removing also other non-stellar objects (or parts of them): this is called uncertainty, which is inherent in any data acquisition and processing procedure. In general, you cannot simply exclude the stars from most processing tasks. For example, you cannot remove all the stars to deconvolve an image, or the result would be simply wrong. You have to understand why stars are singularities, learn to predict where and how they will cause problems, and apply seriously conceived and developed solutions to protect them. That said, our StarMask tool can be used to generate a mask including most of the stars in an image, if necessary; see an example here.

Coma correction

Nothing to add to what Carlos has already said about this. However, my position is, once more: if you have comma in your images, buy or build a comma corrector, or use an optical system without comma. But please don't think that a software solution is the actual solution to a hardware problem.

[Geoff]

 

So the only solution to tracking problems is fixing the hardware that is causing them: throw away all wrongly tracked frames, look for the causes of bad tracking in your equipment, analyze and understand them, and fix them. Then acquire the data again. Astrophotography requires the pursuit of excellence, both technically and aesthetically. No software 'magical box' can help you to achieve that.

Nothing to add to what Carlos has already said about this. However, my position is, once more: if you have comma in your images, buy or build a comma corrector, or use an optical system without comma. But please don't think that a software solution is the actual solution to a hardware problem.

Hola Juan
This is a very interesting and honest way of looking at astrophotography and not something I followed before getting involved with PixInsight. I'm sure many, if not most, astrophotographers have no qualms about tweaking the image to round up stars and remove other minor defects. But yes, I think your thoughts on the matter are the correct way to go.
Geoff