jjosefsen

3 minutes ago, Adreneline said:

Hi.

That looks like what I ordered:

https://www.firstlightoptics.com/baader-diamond-steeltrack-focusers/baader-steeltrack-diamond-rt-adapter-m90x1-for-refractors-gso-rc-scopes.html

Like you, I could have done without the extra expense but trying to compensate for the droop was like trying to solve the wrong problem and constantly chasing my tail. I'd fix one problem and create another.

One word of warning! With the Baader fitted I've found it very easy to find focus with my ASI294MC and my Canon M6 MkII with the supplied spacers. I don't use the RC for narrow band.

However, on the odd occasion I want to use an eye piece to allow friends/family to do a bit of stargazing, just using a SW 28mm eye piece, there is no way I can achieve focus with the Baader as the drawer tube is too long. I have to refit the stock focuser. It's a minor thing but just thought I'd mention it.

HTH

Adrian

Thank you, and thanks for the headsup.

If I may I have one more question..

Does it have built in collimation? It doesn't look like it, but wanted to be sure.

21 hours ago, Adreneline said:

My GSO 6" RC suffered vey badly from droop in the focus unit. I replaced it with a Baader Diamond Steeltrack and it made a huge difference.

Adrian

Hi,

I was looking at a BDS focuser,but they don't make one with a M90 flange as such..

But for thir refractor version of the BDS it is possible to buy an adapter for Skywatcher Refractors with M90 connection to scope, is this what you did?

Adapter: https://www.baader-planetarium.com/en/rt-adapter-m90x1.5-diamond-steeltrack-(skywatcher).html

Focuser: https://www.baader-planetarium.com/en/2"-bds-rt-baader-diamond-steeltrack.html

So I tried something else just now..

Used a laser to make sure the focuser was pointing straight at the center of the secondary mirror, and rotating the laser to make sure it still pointing straight at the secondary dot.

When I then checked the collimation with my REEGO, and even jsut looking into the focuser it is obvious... But circle that you are supposed to see around the primary mirror, that has to be concentric or equally tick all the way around is completely misaligned.

Does this mean that I have a misaligned focuser? And would the tilt aadapter work in this scenario?

8 minutes ago, Adreneline said:

My GSO 6" RC suffered vey badly from droop in the focus unit. I replaced it with a Baader Diamond Steeltrack and it made a huge difference.

Adrian

It could be yeah... I am just hessitant to throw more money at this scope than I already have..

24 minutes ago, vlaiv said:

I'm not entirely sure if angled focuser will present itself like above - one side of focus ok and other not concentric.

What could happen is focuser tube sag.

Good image is with focuser tube moved inside focuser - and bad image is with focuser tube drawn outside, right?

Maybe it is focuser tube that is tilting with respect to focuser when you rack it too far out. Do you have any sort of 2" extension like this one:

https://www.firstlightoptics.com/adapters/astro-essentials-2-35mm-focus-extension-tube.html

that you can use to get out focus image - without racking focuser that much out?

Yes good is inside, bad is outside.. So sagging makes sense as a possible culprit.

Checking the outside focus with extension tubes is doable I think, will give that a go.

Thanks for the feedback.

4 minutes ago, vlaiv said:

First step would be to loose focal reducer.

It could be some silly misalignment in reducer lens or reducer not being square with focuser or whatever.

You want to take that variable out of the equation.

I had the same issue with an Astro-Tech Field Flattener, but I guess the same point remains - the FF could be faulty.

Should be clear tomorrow, I will try again without anything else in there.

I am wondering if maybe it could also be that the focuser is just not square to the primary mirror, and I would need a tilt plate adapter.

I have been trying to collimate my RC6 using stars and a variation of the DSI method and using a REEGO Pro tool (similar to the TS LED Collimator).

When I look into the collimation tool it looks absolutely bang on, even then I would expect to have to do some minor tweaks on a star..

But something is very wrong, and not just small tweaks I think.

Camera is a AA 1600m and a TS CCD47 reducer at approximately 85mm of backfocus.

This is the edges of my field, when the large star in the middle is in focus (used bhatinov mask), NOT GOOD.

This is a star defocused INSIDE of focus, looks OK I think (except some specks on the mirror).

This is the same star defocused OUTSIDE of focus, this is much more worse..

Does anyone know if the fact that the star shape is altered so much is due to some sort of image train shift / sagging of the focuser?

Any input is much appreciated, this thing is really driving me nuts!!

22 hours ago, tooth_dr said:

Haven’t got any further than photo below. I bought a new scope so swapping over bits and running new wiring, setting up spacing with the FR, etc. Possibly looking clear Sunday so aiming to get a run then with the new filters, I’ll post images here 👍🏻

 

This thing looks insane

I have to ask.. what do you have on there? APM something.. 

19 minutes ago, vlaiv said:

Yes.

Here is rather crude example.

Say you have 0-1 range and you have "fixed precision" of 100 units in that range. I'll be working with decimal numbers to make it easy to understand and calculate.

Your image consists out of three pixels: One bright, one medium and one very faint.

Bright will be 0.851

Medium will be 0.5

Very faint will be 0.001

That is in "floating point representation" - or you don't need to worry about precision.

If you write that our fixed precision - look what happens:

0.851 will be written as 0.85 (only two decimal places allowed) - you loose here very little of the value, error is (0.851 - 0.85)/0.851 = ~0.12% of error

0.5 will be written as 0.5 - here due to number it self you don't loose anything by rounding

0.001 will become 0 - here you lost all information. That is the problem with fixed point format - you loose information in very faint areas.

But what will happen if we apply stretch first? Stretch that we apply can be represented by power law - raising to certain power. Here we will use power of 0.1 (equivalent to gamma of 10).

0.851 ^ 0.1 = ~0.984 = 0.98 when we round it to two digits

0.5 ^ 0.1 = ~0.933033 = 0.93 when we round it to two digits

0.001 ^ 0.1 = ~0.5012 = 0.5 when we round it to two digits.

Now we did not loose any of pixel values completely. Nothing was rounded to 0 we still have values that are very close to those in full precision. In fact - if we "inverse" those fixed point numbers - we will get very close to original values:

0.98 to the power of 10 is ~0.817073

0.93 to the power of 10 is ~0.484

0.5 to the power of 10 is  0.0009765625

As you can see - error is larger where we had large signal to begin with and very small with very small signal.

You can view all of that in another way:

Linear data and fixed point format - uses equal precision for both high and low values in the image - it introduces same level of rounding error.

Stretching and then using fixed point format - uses high precision for faint parts and low precision for bright parts - so rounding error is small on faint stuff and high on bright stuff - which is better from SNR perspective as faint parts already suffer from poor SNR and don't need more (rounding) noise added.

 

 

Honestly that makes perfect sense, thank you for that explanation.

Any processing on linear data needs to be done in 32bit preferably and then I can go to 16bit when non-linear.

I already have a workflow in mind then..

17 minutes ago, vlaiv said:

....

Anyway, back on your question.

Doing processing in 16 bit is real concern and I would not do it. At least - not directly like that. I discourage people from saving stacks in 16bit format and then using PS or other image manipulation software to stretch that image. That does not make sense.

However, with Starnet++ - you can use 16 bit format because StarNet ++ expects stretched data. If you take 32bit format and stretch it - you will take all those faint low SNR areas and make numbers big enough to be comparable to other numbers in the image. You will compress dynamic range - and by compressing dynamic range - you'll again be in the zone that is handled with 16bit format ok.

Only issue with this approach is if you need linear starless image for whatever reason. You could do mathematical stretch - like gamma with known number - then perform star removal and then undo stretch. However, your precision will suffer somewhat and resulting linear data will have some quantization noise injected in it (because you rounded numbers when you used fixed point 16bit format).

Makes sense?

Thank you for that explanation, I need to re-read the top part again to understand all of it.

But in regards to the quoted part..:

If I do my stretching of the fits files in Affinity Photo (which supports 32bits) and then convert from 32bit to 16bit after,  then it is "OK" if I understand you correctly.

Because by stretching the data before I will have done dynamic range compression? 🤔

Hi,

I have been playing with Affinity Photo for image processing, and I find that I really like the application and the more visual way of processing the images, compared to for instance PI (I know I am probably crazy...)

One problem I have though is that in order for me to use either Starnet++ or StarXTerminator for separating stars and nebulosity, I have to go from 32bit to 16bit..

But I am honestly struggling a little bit with wrapping my head around how much of a difference it makes in the end?

I appreciate that 32bit images contain a lot more information than 16 bit images. But then again I am using a camera with a 12bit sensor, so does it really matter?

Any insights or thoughts are welcome!

Even if you have ways of separating stars from background with as good results as these machine learning plugins do, then that is also appreciated.

On 16/11/2021 at 22:26, FrenchyArnaud said:

Ok, so after HOURS of digging, googling and reading the doc... Nope, not possible directly. It looks like a big oversight to me from the devs, I am dropping them an email. I am left with two choices : 

1) as suggested, dithering on every frame and set a settle time for the mount that is much more than needed;
2) switch to APT.

I am installing APT and will try both as soon as I have a tiny bit of a pretend of a sky - we are closing in on a month with 100% overcast so I have no idea when that will be! 

EDIT - After a quick chat with the devs, I learnt that the sequencer has been upgraded for this in the V2 currently beta, which I will test immediately! When the beta becomes main, the sequencer should therefore allow precisely that. 

 

The beta is very stable, so don't feel like it is a big risk using that.. It could be in beta for quite a while.

This is an absolutely fantastic image.

The FOV is impressive and the processing is just to my liking, the colors, the background... 👌

There are some artifacts around some of the brighter stars, which could look like results of blendings images with a pronounced difference in star sizes (ha vvs oii perhaps?).

But this one for sure goes into the bookmark folder I have for images with the look and feel i like..

What a beautiful build..! Way to go!

On 23/07/2021 at 14:10, Clarkey said:

I have now spent the last two nights outside trying to finish the collimation on the RC8. Reego got it pretty close, but the star test was still a bit uneven. I have been using the DSI method which has been recommended from a number of sources, but despite 5 hours of adjustment I still cannot get it quite right. As it is not dark enough for imaging at least I do not feel I am wasting precious clear skies.

A Procedure for Collimating Ritchey-Chrétien and Other Cassegrain Telescopes (deepskyinstruments.com)

I can get the central area spot on by the primary adjustments, but the perimeter stars are slightly mis-shaped but balanced across the image. (All the outer stars are pointing slightly towards the edge of the image, as per image 3 on page 16 of the procedure). Does this mean I need to move the secondary mirror inwards slightly to extend the FL? I have increased the FL slightly, but I do not want to go too far in case I am doing the wrong thing.

Just to add - the star shapes in the OAG are poor which I would assume would also be linked to the collimation.

Any guidance greatly appreciated.

Hi,

Did you manage to get your RC sorted?

I have spent a lot of hours trying to sort mine out now. 

I feel like I am just chasing my own tail though, it never really gets really good.

On 25/08/2021 at 19:14, Nikolas74 said:

I didn't had any luck so at the end I quit mad use the Stellarium landscape. 

Too much work to do maybe in the future I will try again. 

Following this guide it took me 15 minutes.

It's already been mentioned, but: Nighttime Imaging 'N' Astronomy – An astrophotography imaging suite (nighttime-imaging.eu)

It is truly a great piece of software, and it is free!

13 hours ago, vlaiv said:

Maybe you should think of it this way:

If you have your secondary out of collimation - no stars will look good, but if your primary is out of collimation - your secondary can compensate for central part of field. This means that star in center will look ok and when defocused - you'll get concentric rings, but edge stars will be a mess.

That is why procedure is as follows:

1. adjust primary so that stars have roughly the same FWHM in each corner (same level of defocus due to field curvature)

2. then adjust secondary so that you get concentric rings in the center of the field

then go back to point number 1 (because messing with secondary will change edge stars again but less this time)

Hope this helps.

It’s not exactly what I’ve been doing, but it makes sense. I will try it. 
 

What confused me was the fact that they seemed to collimate different on/off axis differently. But I suppose it doesn’t matter as long as the optical axis just ends up aligned. 

On 13/08/2021 at 08:56, Doversole said:

Thanks @vlaiv, I tweaked the secondary with a bright star in the centre of the frame, then took another picture of M27. Much better indeed and not that difficult. Thanks again for your help!

This is looking great! I wish my stars looked like that.

On 12/08/2021 at 10:30, vlaiv said:

Just fix the secondary and repeat the test.

Tweaking secondary is rather easy - find bright star - place it smack in the center of the frame, defocus - and tweak secondary until you get concentric rings.

 

Sorry to but in here, but I am working on collimating my RC6 as well, and have a question. 

I have been using this Deep Space Place to collimate, but haven't gotten it really great yet.

But last night I was looking at the DSI method, and noted something.

DSI: On axis collimation done with primary mirror, off axis collimation done with secondary.

DSP:  On axis collimation with secondary mirror, off axis with primary mirror.

Does it not matter in the end? I have an aweful lot of weirdly shaped stars around the edges.

That is some setup!!

For only an hour per panel I think it looks very good! 👍

Hi,

I doubt this is vignetting, your images should be getting darker not brighter around the edges.

Try calibrating without flats, does your issue persist? I'm going to guess that they are - because I have the same problems with the same camera.

It seems to be in the dark frame calibration and for me it is only a problem with broadband filters..

But I would love to see what happens if you try to calibrate without flats and compare, and without darks and compare.

Hi,

I am shooting LDN 1235 at the moment, and I was considering just doing R,G,B and forgoing luminance and just creating a synthetic luminance from the R,G,B subs later.

I've done similar things before with pretty good results: https://www.astrobin.com/full/412663/B/?nc=user

I really want to catch the faint colors of the reflection nebulae and the brown dust in this object, and was thinking that going really deep on all the color channels would do that, and possibly not missing much as it doesn't appear there is too much fine contrasty detail to be had..

Opinions would be very welcome. :)

Good lord that is something else!