LRGB data M31

[tooth_dr]

I've attached my M31 data to see if anyone wants a go at it.  This would be of great interest to me to see how my processing can develop, especially around star management on the luminance channel.  I've attached the RGB data, focusing issues, so currently deciding on where to go in terms of focusers.

 

M31-tak-Lum-20s.fits M31-tak-Lum-120s.fits M31-ED80-Red.fits M31-ED80-Green.fits M31-ED80-Blue.fits

[bottletopburly]

processed in Startools 1.7 alpha 

[tooth_dr]

2 hours ago, bottletopburly said:

processed in Startools 1.7 alpha 

Class!  The were a few gradients to deal with and you’ve done a great job!  

[Laurin Dave]

Hi Adam..

Here's my attempt....  Pixinsight for background extraction, registration and cropping and stretching (simple histogram stretch) of the RGB and Lum (RGB much less stretched then the Lum) and Photoshop for a a bit of saturation, combining Lum (120sec only) with the RGB using it in 5 layers at 20% opacity and local contrast enhancement..  Looking at your data  Green and Blue focus are a bit wonky and it also looks to me as if there's coma/spacing issues with your ED80,  also the Tak stars seem a bit elongated even though Pixinsight measures them as very round, the 20s and 120s images look similar in this respect which I guess suggests its not flex in the guiding ..   FWIW I use Lakeside autofocusers..   

Dave

 

[tooth_dr]

2 hours ago, Laurin Dave said:

Looking at your data  Green and Blue focus are a bit wonky and it also looks to me as if there's coma/spacing issues with your ED80

Dave, I really appreciate you picking up on the spacing issue.  I actually wasnt aware of this, and now that it's pointed out it's obvious.  I think I may now realise the cause.  I had been using my Atik383L+ on the ED80, but swapped to the QHY9 in May.  The QHY9 I assumed had the same back focus as the Atik (17.5mm) but in fact the QHY9 I have is the mark1 model with a 15.5mm backfocus, so I am 2mm too close to the sensor.  I wonder does that tally with the star shapes.

I attached a corner crop from RGB subs below:

 

 

3 hours ago, Laurin Dave said:

Tak stars seem a bit elongated even though Pixinsight measures them as very round

 

Also I agree the Tak stars arent totally round, they appear somewhat elongated.  Any ideas of the cause?

 

 

[Laurin Dave]

Hi Adam

Based on the diagrams I've seen (https://altaircameras.com/howto-adjust-sensor-reducer-flattener-spacing-for-better-star-shapes/) it looks like the senor's too close so if your spacing/star shapes were good with the Atik camera I guess you just need to add a 2mm spacer..  that said I'm no expert and am struggling to get the spacing right on my WOGT71/Flat3A...  As for the Tak I have no idea I'm afraid..  maybe other Epsilon users can help eg  @Allinthehead

Dave 

[Allinthehead]

On 22/08/2020 at 15:10, tooth_dr said:

Also I agree the Tak stars arent totally round, they appear somewhat elongated.  Any ideas of the cause?

I'm not sure what the cause is but i get similar issues with mine. You can see the large star with the spike center left is out of focus where as the large star center right is better. My suspicion would be tilt but it's hard to tell. Maybe ccd inspector could give you the answer.

[tooth_dr]

On 23/08/2020 at 18:43, Allinthehead said:

I'm not sure what the cause is but i get similar issues with mine. You can see the large star with the spike center left is out of focus where as the large star center right is better. My suspicion would be tilt but it's hard to tell. Maybe ccd inspector could give you the answer.

Hi Richard, thanks for the reply.

I quickly ran my M33 data through CCDI and it reported a 9% tilt.  I then ran my M31 data and it reported a 5% tilt.  I also ran an H alpha image of NGC7000 and it reported 0% tilt so I’m not sure what to make of it all.

The Epsilon uses a screwed together configuration for FF, camera and EFW.

I dont know where to start but will try and look into it. There is a tilt adjustment on the focuser but I don’t want to start messing with it without diagnosing the problem properly first. 
 

 

[ollypenrice]

The others have done a nice job of this so I'll offer a different take on it. When trying to flatten the Lum in DBE I found it very difficult. The problem is that we want to retain the faint and considerably extended outer glow around the galaxy but lose the gradients at around the same brightness. What DBE was not taking care of (and what it isn't designed to take care of) was a slight imperfection in the mosaic's levels to start with. To get the best out of this data I would, therefore, go back a step and spend longer on the joining of the panels. You've joined them at the linear stage. There's something to be said for that but when it throws up a problem an alternative approach might prove better.

What I would do is edge crop the two panels and DBE them. I'd then give them a 'half way' stretch and combine them in Registar. This output image will become a template for the final one, it won't be the final image itself. I'd also save the two 'registered-calibrated' halves of the mosaic from Registar and open them in Photoshop. Paste them over the template and measure the background values of both halves where they overlap. This will allow you to check how well Registar has equalized the levels in both halves. In all probability it will have done a good job, as your software had done, but not a perfect job. Now you can aim for hand-measured perfection by locally adjusting one or both halves to match the other. You can use Levels or, for more local control, the Dodge and Burn tools. You can use a feathered eraser to reduce the contribution of a stubborn bit to the final blend. And once you've flattened the blend you can run the Equalize filter on it to test, brutally, the real smoothness of the blend you've created. Discard the Equalized image: it's only there to expose imperfect blending.

In a nutshell I'd spend longer on the joining of the two halves before trying to proceed. DBE won't eradicate mosaic artifacts.

Olly

Edited August 28, 2020 by ollypenrice

[Xiga]

Brilliant post Olly. Plenty of food for thought there! I do wonder though how hard this method would be in reality for those of us not in the same league of PS skills. 

I haven't looked at the data myself, but it might be a good idea Adam to share the stacks for the two Lum panels. Then we could see if there is a better starting mosaic possible. I know you use APP for stacking. Did you use any LNC (Local Normalisation) settings when creating the mosaic? I recently did a quick 6 panel mosaic in APP. With no LNC, the varying brightness of individual panels was very noticeable. But with the right settings i found it blended really, really well, so much so that I don't need to amend any of the overlaps manually. Olly's idea of using an Equalized stretch to show up small imperfections is a good one. With only 2 panels it will stack very quickly, so you could just do several stacks at different settings (Degrees and Iterations) and Equalize them in PS to see which works best. 

Edited August 28, 2020 by Xiga
Spelling

[billhinge]

Here is my effort

 

[tooth_dr]

Thanks for that @billhinge

I should have posted my own effort:

[billhinge]

I  took a flight of fancy with  this version 😂

[tomato]

I'm a bit late to this, but here is my effort, processed in StarTools v1.6, following the default workflow. It was important to crop out the areas which were not completely overlapping, as the gradient removal tool does not do a proper job.

[tooth_dr]

Just now, tomato said:

I'm a bit late to this, but here is my effort, processed in StarTools v1.6, following the default workflow. It was important to crop out the areas which were not completely overlapping, as the gradient removal tool does not do a proper job.

Brilliant!  I've since adjusted the spacing for my ED80 and Tak, so looking forward to improving on star shapes.  

[tomato]

There is a feature in Startools to improve star shapes but I didn't use it on the image.

[tooth_dr]

58 minutes ago, tomato said:

There is a feature in Startools to improve star shapes but I didn't use it on the image.

Thanks! I'm not using that software, and hoping to correct it at source

[wimvb]

Here's my version. As @ollypenrice already noted: before stitching panels together, they need to be flat and have the same background level. I could reduce the gradients somewhat, but they were eating into the galaxy.

Anyway, as always: messed up in PixInsight

[ollypenrice]

11 hours ago, wimvb said:

Here's my version. As @ollypenrice already noted: before stitching panels together, they need to be flat and have the same background level. I could reduce the gradients somewhat, but they were eating into the galaxy.

Anyway, as always: messed up in PixInsight

That's excellent. The only thing I'd add would be a blurring of the inner core which looks slightly stellar.

Olly

[wimvb]

18 minutes ago, ollypenrice said:

That's excellent. The only thing I'd add would be a blurring of the inner core which looks slightly stellar.

Thanks, Olly. It is a bit stellar indeed. I wanted to show the very faint structure near the core. Normally I would spend more time on the hdr process that I used, and probably blend the 20 s master image into the 120 s master. For this image, I only used the 120 s master.

[ollypenrice]

2 hours ago, wimvb said:

Thanks, Olly. It is a bit stellar indeed. I wanted to show the very faint structure near the core. Normally I would spend more time on the hdr process that I used, and probably blend the 20 s master image into the 120 s master. For this image, I only used the 120 s master.

Photoshop, Layers, ten seconds! 👹🤣

Olly

[fwm891]

Would PI's Linear Fit not have sorted the differences?

Couple of points - Should the  image be rotated 180° and it's a touch yellow thus reducing the blues....

Great image

[wimvb]

2 hours ago, ollypenrice said:

Photoshop, Layers, ten seconds! 👹🤣

Olly

Quelle horreur 

[wimvb]

1 hour ago, fwm891 said:

Should the  image be rotated 180°

Not if you're from down under. 😉 Personally, I don't care too much about image orientation in astro images, unless there is a definite asymmetry. The horse head nebula should never be mirrored, for example.

2 hours ago, fwm891 said:

it's a touch yellow thus reducing the blues

The blue was weak to start with, and I didn't want to push the colour noise too much. This image should ideally be reworked from the original data. But that would be a major process.

2 hours ago, fwm891 said:

Would PI's Linear Fit not have sorted the differences?

Maybe. I use background neutralisation and colour calibration in pixinsight. These processes work on the three colour channels simultaneously  but in the same manner as linear fit does on mono images. Because I didn't know the pixel size that was used, I couldn't apply photometric colour calibration.

[tooth_dr]

1 hour ago, wimvb said:

Because I didn't know the pixel size that was used,

It was 5.4um.  Good job on the processing. Blue was weak enough, focus wasn’t good.  I do prefer M31 rotated 180 degrees, but for most objects I agree it’s personal preference.