symmetal

Yes, I've tried using the Arcsinh stretch itself but found it gave saturated or near saturated stars random pixels of 1 colour so gave up using it. Converting to HSV and using the 'Repaired HSV Separation' script beforehand is meant to fix this, but I never found it changed very much. GHS doesn't seem to produce this effect so see if you like its results. There are some good Youtube tutorials on using GHS, and one of them suggested using this 'Colour mode' initially to maintain star colour. Alan

An excellent first image. 😊 Well done! Alan

Great image with fine detail in the galaxy, which makes it look like a 'Shredded Wheat' 🙂 I think you got your sums wrong on your f2 1280mm focal length scope though, which would have an aperture of 640mm or 25". 😉 Alan

Lovely image. 🤗 The surrounding dust almost 'outshines' the usual Horsehead area in the full mosaic. Yes, PhotoMetricMosaic does seem to perform very well in blending the panels without having to do a lot of preparation beforehand. I notice that there's little colour in the stars. I use PI GeneralizedHyperbolicStretch for most stretching operations now, and for the first iteration of around a half strength stretch, I select the Colour Mode in 'Colour Options' rather than the default RGB mode, as that preserves the colour during the stretch, similar to using an Arcsinh stretch, and then use RGB mode after for further streches. Alan

Not quite. It's the thickness of the filters that matters which is 2mm for the Zwo narrowband filters. You've confused the 2mm optical thickness with the optical bandpass width which is 7nm (nanometres). Note it's nm and not mm for the bandpass width. 1 nm is 1 millionth of a mm. 😉 The Zwo ASI2600MM has a 2mm thick protect window so your total glass in the way is 4mm. 1/3 of 4mm is 1.33mm. So your FF adjustment should be 5.2 + 1.33 which is about 6.5mm. You don't need to be supercritical in this setting. For small sensors it won't make any difference whether you use 5.2 or 6.5mm but the larger the sensor diameter the more necessary it becomes to get the spacing right. 🙂 Alan

Yes, your calculation is correct. 🙂 However, you haven't allowed for the glass in the way between the FF and sensor which extends the required back-focus distance by around 1/3 the total thickness of the glass, due to the different refractive indices of air and glass. So if you have say 2mm thick filters and 1mm sensor protect glass, for a total of 3mm. you need to extend the back focus distance by 1mm which makes your FF setting 6.2mm rather than 5.2mm. Manufacturers back focus distances are quoted for only air between the FF and the sensor, and it's up to the user to change this distance as necessary, if anything other than air is introduced between them. Alan

Oops. I missed the actual link in your post. Alan

I like your latest one a lot.😊 Having the stars more noticeable shows that areas where the stars are denser are the areas that were made lighter by SXT, but the actual stars being present hides this effect to some degree. M27's 'wings' stand out more too now. I'll have to try this with my RASA 11 to see what the extra focal length brings, as well as adding some SII for full SHO. The main advantage of the RASA 11 I think, is the ability to easily use a mono camera with a filter drawer, as it has 72.8mm of back focus to play with if you use the Baader UFC system, (necessary for full frame cameras), or 55.0mm back focus using the Celestron M48 adapter. It does mean getting 'fast' narrowband filters though which aren't cheap in 2" size, being £620 each for the Astronomik ones. @windjammer There may still be an issue with recently made RASA 8 scopes, with the mirror edge causing large asymmetric flares on brighter stars. I had to return three RASA 8 scopes a year or so ago, because of this and Celestron ended up returning their entire stock back to China to be fixed. FLO are still listing 90 to 120 delivery as has been the case for the last year, so it's worth checking the latest situation with FLO. Because of the hassle I had Celestron, along with FLO, offered me a RASA 11 at a reduced price which I was happy to accept. 🙂 Alan

Hi Wim, I looked on Aladin and saw references to your dwarfs A and B on Hyperleda but couldn't find the info on C and D. Loading the NED database showed many extra galaxies but they don't seem to differenciate on galaxy type to know whether they are dwarfs. I'm not an expert at using Aladin so maybe missed something. NGC4216 and VCC165 are noted as being GinPair which I thought implied they were drinking buddies 😊, but it apparently just means 'Galaxy in Pair of Galaxies' which is a bit disappointing. Alan

My processing of the Cocoon Nebula using SXT seemed to work well even though the star density is similar to your M27. Whether this being RGB gave more information to SXT to work with I don't know. 🤔 Neutralizing the background colour cast should also help your image. 🙂 Alan

Yes, your second processing shows M27 a lot better. It looks like SXT had a hard job trying to construct the background and created the mottled look. This RGB image shows how little background there is visible for SXT to work with. A second processing with less background stretch combined with your current M27 processing would look better in my opinion. PS layers with a very soft edge mask would likely do it. 🙂 Alan

A very interesting image, particularly with the extra information Wim. Thanks for posting. Where did you find the information about the dwarf galaxies? Alan

I found this tutorial very useful on PI SHO processing and is what I used for my Pelican Nebula. 🙂 Alan

I swapped over to using GSS a few months ago and have have no problems. It can be installed alongside EQMOD. Just follow the Quick start guide in the documentation and you should have no problems. I swapped to it to avoid the issue of having to manually clear out the pointing data that is stored by Eqmod, each time it's started, which can stop it centreing on the target. A handy feature of GSS is the 3D model of your mount/scope orientation so you can quickly see where the weights are. Alan

Hi @Petrol, This is my first mosaic too, apart from Moon mosaics which I did manually, and I've only been using PI for a few months now. I went for GradientMergeMosaic because it implied it specialized in correcting gradients, but PhotoMetricMosaic does that too, and just as well if you combine the panels in the 'best' order. I only had a 12% overlap when capturing the mosaic, but the more overlap the better in enabling the software to more accurately match the panels, so I'll have a higher overlap in future. The documentation with PMM is very informative and worth reading through. It actually says that background extraction, DBE or ABE, isn't necessary before using PMM and can be better applied after, but if you do do it before ensure it's done before you run MosaicByCoords or you'll end up with near black areas. I did use BlurXTerminator and NoiseXTerminator on the panels beforehand but the PMM documentation says it's best to leave that until the mosaic is made as they can change the star profiles which affects the PhotoMetric part of PMM. Even though I did this wrong it still produced very good results. 🙂 Alan

I intended to initially, but the indidual panels didn't show any obvious gradients, and some didn't have any background anyway, so I thought I'd try them as they were, without DBE, and see how they matched. The mosaic turned out much better than I had expected considering the Moon was around, though it being fairly low in the sky and around 120 degrees away helped. If I also try adding OIII and SII I'm wondering how well they'll register with the Ha. As long as I specify the same pixel scale, centre coords and projection for MosaicByCoords, I hope that's enough. Slight rotation throughout the mosaic may be an issue. Alan

I tried PhotoMetricMosaic making 2 columns of 4 panels from the botom up and this improved the vertical gradient a lot but when joining the two columns the bottom 2 panels still didn't match, so I tried instead creating 4 rows of 2 panels and joined the 4 rows from the bottom up. This was much better as shown here 😊 Just an overall left to right gradient which is easily fixed. This is very good considering that no background extraction or LinearFit has been applied here. So no need for GradientMergeMosaic and pinched stars, or the DynamicPaint tool for which I've still not had a serial number sent. 🧐 I paid by Paypal so should be able to get a refund if it doesn't arrive. Alan

It's a tantalum electrolytic capacitor. It's quite likely a similar value to C39, above and to the left, so see if any visible remaining markings match. Towards the bottom of this webpage it shows typical markings for tantalum types. Note that the end with the dark line is the positive terminal, opposite to aluminium electrolytic can type electrolytics where the black marked end is negative. The chamfered ends of the pcb silk screen indicates the positive end too. When they first arrived on the scene in the late 1970s, tantalum capacitors offered much higher capacitances in smaller packages than the usual aluminium electrolytics, and were widely used until it was found they had an annoying habit of going short circuit and so burning up, for no apparent reason, when they fell out of favour. Since surface mount components came about they seem to be quite common again. I assume their construction has improved to avoid this feature, but in the absence of any other components looking stressed, it may have just failed on its own. Alan

Your RA looks like mainly a backlash issue. You say you're well balanced but that's not ideal for gear driven mounts. It's normal to make the balance 'East side heavy' so that the side of the mount facing East is trying to swing down under gravity so the RA drive gears are always engaged and the RA drive is always having to push the East side up. In the northern hemisphere anyway. This way, RA backlash shouldn't cause a problem, as the RA is only driving in one direction or stopped, never in reverse. I have an EQ8R and I balance such that when the bar is horizontal and the clutches off, it just begins to fall on its own under gravity. If the bar is nearer vertical then this gravity inbalance effect is reduced so if I have poor guiding when the bar is near vertical I attach a weight pulling horizontally on the bar to simulate the gravity inbalance as shown below. The pulley the cord goes over needs smooth bearings or it can cause sudden jerks leading to large RA spikes every minute or so. Dec backlash can be more problematic as Dec needs to drive in both directions. Making the scope balance back heavy helps for the same reason as above. Again when the scope is near vertical this has limited effect so a weight added as before trying to pull the scope to one side should help. Dec backlash is then only really noticeable when a dither command has driven the dec across the backlash area and it can then take 30 secs or more for the Dec to settle. You don't say what altitude your scope is pointing at when you have your issues. If pointing closer to the horizon guiding will invariably be significantly worse than when pointing higher in the sky. When assessing the mount guiding you need to be pointing at around 50 to 60 degrees in altitude, to minimize atmospheric effects spoiling your results. With PHD2 you can run the guiding assistant for 10 minutes to see what the periodic error is like. As long as there are no sudden large jumps in the curve and it tends to follow a fairly smooth curve then guiding should be able to correct it without problems, even if the total periodic error is around 20" or so. Your guide star profile doesn't look too good, and is rather bloated. OAGs often have poorly shaped stars but as long as you choose a star which isn't too overexposed they seem to manage OK. I haven't done any backlash adjustment, or anything else, on my EQ8R and am happy with its performance. 🙂 Alan

I tried PhotoMetricMosaic and it performed very well apart from the bottom left panel where the join is visible and the background is significantly brighter than the rest. 🤔 GradientMergeMosaic blended this panel in much better although both methods seem to show the background getting progressively lighter from top to bottom. They were taken under a partial Moon and where astro dark was running out so not the best of conditions. I used dnaLinearFit on the GMM panels to make the overlapping areas of equal intensity which likely helped. I'll try using these dnaLinearFit panels through PMM to see if they perform better. For PMM I created 2 colums of 4 panels and then joined the two columns together. I could try 4 rows of 2 panels and see if that makes a difference. There's evidence of misregistered stars towards the edges of the mosaic where the panels meet too. These are 8 ASI 6200MM Ha images binned 2x2 in software to avoid having a mosaic of 18000 x 24000 pixels, and only 30mins per panel with a RASA11. It was just an exercise to see how well mosaics worked under less than ideal conditions. 🙂 Alan

Thanks old_eyes. That's two votes for PhotoMetricMosaic. 🙂 I'll give that a try. Alan

@Fegato Thanks for the info. Yes, the PixelMath method works but is very cumbersome when you have quite a number to do. It would be useful if PixelMath had Object Oriented parameters where you could pass for example the Preview Box name to the PixelMath function and the expression would then have access to the box coordinates without having to enter them manually each time. I can now see that the CloneStamp method could work if GMM is in Overlay mode and the panels are added in the correct order but I wanted to use Average mode as panel order doesn't matter and the merging should be smoother. The PixelMath method method should work in either mode as true black pixels are ignored by GMM. I did try the DynamicPaintbrush tool on a 30 day trial and I believe it will do what I want. It has the same interface as the CloneStamp but just paints black or white pixels rather than cloning. Also blur 0.0 acts correctly too, where no edge blending occurs and a hard edge black circle is painted. This enables GMM to ignore the painted pixels as they are true black of value 0.0 and so doesn't try to merge the painted area with the other panel like it does with clone stamp. I went to try it using GMM but it then said my trial period had expired, (after 15 mins of use). 😲I'm sure it'll work, so I took the plunge and paid the $4.99 registration and am now waiting for the serial number to be emailed. DeepSkyColors released it in 2021 with the announcement of many follow up versions and other PI utilities but they've gone very quiet since. Hope they do send a serial number. I'll try the alternative scripts you've mentioned and see how they perform. The DnaLinearFit script may balance the panel levels well enough that the gradient merging isn't so necessary. Alan

The documentation for GradientMergeMosaic just says to use the CloneStamp to remove offending 'pinched' stars on panel edges. 🧐 This tutorial also uses Clone Stamp but left to defaults apart from the radius. I tried it and this produced far worse results as almost none of the cloned pixels will be black at 0.5 softness, and they so you ended up with each 'fixed' star surrounded by a dark halo the size of the clonestamp. 😟 The Astro Imaging Channel had a talk by David Ault on GMM and at 45:30 he describes what he does about pinched stars. No mention of clone stamp. In summery he draws a preview box around the offending star, notes the x and y extends of the box, and enters them into a PixelMath equation to replace every pixel inside the preview box with zero. Then repeats for every pinched star. My 4x2 mosaic has at least 2 pinched stars on each edge, and 20 overlapping edges so I have to go through that palaver at least 40 times. There's a third party PI addon called DynamicPaintbrush which may do what I want, and let you paint in black with a hard edge, and there's a free 30 day trial so I'll try it out. Else it's export all the panels as tiffs into PS, paint out the stars and reimport back into PI. This means it's 16 bit rather than 32 bit fp which may affect the merging though so I don't really want to do that. Why's it so hard. 🤔 Alan

I've been building an 8 panel mosaic using MosaicByCoords to create the 8 panels, and DNALinearFit to intensity match the panels, which has worked very well. I then used GradientMergeMosaic to blend the panel edges together which also worked fine, apart from the known issue of bright edge stars causing 'pinched' stars as shown here. The mask shows the panel edges. Here's the offending star on the top panel I used CloneStamp to copy some black over the offending star as a recommended solution on the PixInsight forums. However when re-running GradientMergeMosaic it fixed the star but a faint outline of the clone stamp is left. I think this is because the edge of the clone stamped area is still blending into the image background over a few pixels, and is not a hard edge, even though I've set the softness to 0.0. The preview circle still shows it blending at softness 0.0. GradientMergeMosaic will only ignore true black areas so is treating the blended edge as image background and tries to merge it causing this effect. is there a way to effectively clone stamp with a hard black edge, and not having it try to blend the cloned edge? Or is there some other method which is quick and easy to achieve this. As the PI forum recommends this method, there must be a way to do it. Any PI experts able to help? 😊 Alan

The Zwo manual just states that the sensor protect window is AR coated only, and doesn't specify a different window for the colour version like some other cameras, so it passes IR and some extended blue. IR will be out of focus when you're focused on visible wavelengths so will lead to some image blurring. Depending on how well colour corrected the scope is, the shorter blue wavelengths may be out of focus to some degree as well causing noticeable blue halos around stars The UV/IR cut will remove the out of focus IR and the shorter blue wavelengths leading into UV which should improve your image sharpness, and help with any blue halos. The Astromomik UV/IRfilters have three passband widths. L2 is the middle one and is likely similar to other manufactures UV/IR filters. The L3 has a narrower passband which cuts off more off the shorter blue wavelengths as well as the longer red wavelengths so reducing blue halos more. Your posted image sharpness looks quite reasonable, but there's almost no colour present and it's faily black crushed so it's hard to say what UV/IR filter would suit you best. It's worth getting an UV/IR cut filter anyway if the camera itself doesn't have one, and the L2 should be fine, but whether you'd benefit more from the L3 I can't say from your image. The L1 is for very well colour corrected optics so wouldn't be the best choice for mid-price scopes. Alan