Comparison of stacking in DSS, PixInsight and APP.

[des anderson]

THAT`S one amazing image, your hard work as defiantly paid off. Des

[wimvb]

1 hour ago, david_taurus83 said:

Just to add to this, I captured over an hours worth of data last Saturday night on M3, (mainly as an excercise to try and eliminate coma by adding some spacers to my MPCC, which failed BTW) and spent the best part of Sunday running it through the long Pixinsight pre processing. Needless to say, the results are horrific!! Out of curiosity, i run everything through DSS last night and the result is much better. Gradient is even and the result after ABE is also fairly even and should be easy to process out.

80 odd 60s lights at ISO800, 15 darks, 30 flats and 30 bias, dithered hard every 5 subs

 

First and second are the Pixinsight stacks, first stretched and second after auto background extraction.

 

Third and fourth are DSS stack, drizzled, again initial stretch and then ABE.

 

Pixinsight took many hours on Sunday where DSS took a mere half hour, if that even applying drizzle. I've had decent results using the Pixinsight method so I'm stumped as to whats went wrong here!

 

 

 

Try blinking the images. First the raws, then the calibrated files. Did you use local normalization or large scale pixel rejection?

[alexbb]

1 hour ago, david_taurus83 said:

Just to add to this, I captured over an hours worth of data last Saturday night on M3, (mainly as an excercise to try and eliminate coma by adding some spacers to my MPCC, which failed BTW) and spent the best part of Sunday running it through the long Pixinsight pre processing. Needless to say, the results are horrific!! Out of curiosity, i run everything through DSS last night and the result is much better. Gradient is even and the result after ABE is also fairly even and should be easy to process out.

80 odd 60s lights at ISO800, 15 darks, 30 flats and 30 bias, dithered hard every 5 subs

 

First and second are the Pixinsight stacks, first stretched and second after auto background extraction.

 

Third and fourth are DSS stack, drizzled, again initial stretch and then ABE.

 

Pixinsight took many hours on Sunday where DSS took a mere half hour, if that even applying drizzle. I've had decent results using the Pixinsight method so I'm stumped as to whats went wrong here!

I just deleted the pics from the quote to take less space.

Try to disable the calibration files optimization. I might be wrong about how it's called, I don't calibrate and stack with PixInsight.

[david_taurus83]

1 minute ago, wimvb said:

Try blinking the images. First the raws, then the calibrated files. Did you use local normalization or large scale pixel rejection?

Local Normalisation. I follow the tutorial on Light \vortex Astronomy. I dont know if i can spend another whole day on a relatively minor project! But noted for the next. What does the Blink process entail?

[alexbb]

4 minutes ago, david_taurus83 said:

Local Normalisation. I follow the tutorial on Light \vortex Astronomy. I dont know if i can spend another whole day on a relatively minor project! But noted for the next. What does the Blink process entail?

By blinking, you'll notice if there's a sub not worth including in the final stack. After calibration, if you have a bright sub (a cloudy one) and you try to normalize it, it will be overcorrected and you'll get a result of this kind.

[david_taurus83]

8 minutes ago, moise212 said:

I just deleted the pics from the quote to take less space.

Try to disable the calibration files optimization. I might be wrong about how it's called, I don't calibrate and stack with PixInsight.

The only one thats left optimized is the master dark as I think its scaled to match the different exposure lengths? Flats is left disabled as is the superbias.

[alexbb]

Just now, david_taurus83 said:

The only one thats left optimized is the master dark as I think its scaled to match the different exposure lengths? Flats is left disabled as is the superbias.

Then you ruled that out.

[david_taurus83]

2 minutes ago, moise212 said:

By blinking, you'll notice if there's a sub not worth including in the final stack. After calibration, if you have a bright sub (a cloudy one) and you try to normalize it, it will be overcorrected and you'll get a result of this kind.

Ah, I see, so its a preview of sorts of the calibration files. i still have all the calibration and registered data so the process may not need to take as long. So i could Blink the registered images before Image Integration and remove any dodgy ones?

[alexbb]

7 minutes ago, david_taurus83 said:

Ah, I see, so its a preview of sorts of the calibration files. i still have all the calibration and registered data so the process may not need to take as long. So i could Blink the registered images before Image Integration and remove any dodgy ones?

It's a preview of integration files. If you can do that on the original files only or also on the calibrated subs, I'm not able to answer. As I said, I calibrate and stack with something else, APP in my case. Not that you can't do that with PixInsight, but many times I have data from multiple sources and I find the distortion correction better with APP than PixInsight.

[jjosefsen]

I have had similar problems with some of my images, and avoiding local normalization fixed it.

The developers of PI has specifically said that Local Normalization is not something you should categorically use on every stack.

[Stub Mandrel]

2 hours ago, jjosefsen said:

I have had similar problems with some of my images, and avoiding local normalization fixed it.

The developers of PI has specifically said that Local Normalization is not something you should categorically use on every stack.

Local normalisation (I assume its the same as local equalisation) is a very blunt instrument. I use it on 'normal' images, sometimes blurred and mixed in at 10-15% to get a sort of pseudo HD effect.

It is a useful tool to see what hidden details are in you image as a temporary thing.

[jjosefsen]

18 hours ago, Stub Mandrel said:

Local normalisation (I assume its the same as local equalisation) is a very blunt instrument. I use it on 'normal' images, sometimes blurred and mixed in at 10-15% to get a sort of pseudo HD effect.

It is a useful tool to see what hidden details are in you image as a temporary thing.

I'm not sure it is actually, at least in PI. LN is applied during integration, where local equalization is applied after. But I don't know to much about what those tools do to be honest.

[wimvb]

Local equalization??

Local normalization is used during preprocessing, as described in this thread.

Local HISTOGRAM equalization is a process that is used during post processing after stretching to increase local contrast.

But I've never heard of local equalization. Can someone point me in the right direction?

[jjosefsen]

11 minutes ago, wimvb said:

Local equalization??

Local normalization is used during preprocessing, as described in this thread.

Local HISTOGRAM equalization is a process that is used during post processing after stretching to increase local contrast.

But I've never heard of local equalization. Can someone point me in the right direction?

I think we are talking about the same thing.. ?

[Stub Mandrel]

16 minutes ago, wimvb said:

Local equalization??

Local normalization is used during preprocessing, as described in this thread.

Local HISTOGRAM equalization is a process that is used during post processing after stretching to increase local contrast.

But I've never heard of local equalization. Can someone point me in the right direction?

Local equalisation is what they call the effect in Photo Paint.