symmetal

As AstroNebulee said Roger, you should be able to obtain much sharper images with your scope. I imagine it's at a low altitude at the moment from your location so air turbulence will affect it. Are you keeping exposure low like 5mS or so? In AS3 I usually choose up to around 1000 alignment points on full frame Moon images.

Mono imaging with a filter will help as it limits the range of wavelengths you capture. Green is good for maintaining image brightness while red can give better results in poor seeing conditions. Unless you're going for highly saturated colour images to reveal the subtle colour differences, mono images give a pretty accurate view of how it appears to he eye. 🙂

With the Moon you're not limited in video duration by planet rotation, so take like 4 or 5 min videos and select only the best 5 or 10% for stacking in AS3. If you have an Alt-Az mount then image rotation and the ability of AS3 to de-rotate will be a limiting factor though.

Here are a sample of a stacked image from AS3 and another after using the deconvolution features of Imppg on the stacked image. I use Imppg rather than Registax wavelets on the Moon as not so much enhancement is usually required compared to planets. Taken with FLT98 and 2x powermate with ASI178MM The 178 has smaller pixels compared to the 120 though which helps.

I focus on a nearby star with a bahtinov mask.

AS3 output, 10% stack of around 6000 frames of 5mS exposure. View full size for comparable image scale to your result.

Above image processed by Imppg

Alan

Another winner. Thanks. 😊

Alan

Excellent Image Göran with a very varied collection of objects. 🤗 I have my NBZ filter but am still waiting for the filter holder, and clear skies. 🥲

Alan

You want to set the camera gain to where the HCG (High Conversion Gain) mode is enabled. This ensures lower read noise with little loss in dynamic range as shown in the graphs. It's also around unity gain which is recommended when starting out. There's debate as to what the gain setting is where HCG mode is enabled with quotes of 117, 120 and 121. From the graph it's a bit hard to tell but the difference between the gain values is minimal so gain 121 to be safe as scotty38 suggests.

It's easy to find out though, if you wish, by just taking a bias or a short exposure dark image, ie. exposure with the camera front cap on, at different gain settings. Look at the image statistics readout in your capture software and check the SD (Standard Deviation) value which corresponds to the noise in the image. As the bottom graph indicates the read noise drops significantly at the gain setting (and above) where HCG is enabled. The SD of the image will also drop significantly at this point.

I assume wbr is white balance. This isn't used in astro cameras as you want to record the raw data from the camera before any manipulation. Any colour adjustments are done later during stacking and processing.

Optimum exposure depends on your level of light pollution and 'speed' of your scope. For an f5 or f6 scope in moderate light pollution around 3 mins is a reasonable starting point. If dark skies with low light pollution around 6 mins. For an f2 scope around 1 min exposure. It's all to do with exposing until the noise from your sky background is significantly higher than the camera read noise, around 5 times larger is a commonly used figure. If you want more details on how this is determined and why feel free to ask, but the exposure examples given are fine for starting out.

Leave the camera offset at the default value. It's generally set a bit higher than it need be, but that's not a problem. It's when it's set too low and you get black clipping in your image, that it's bad. 🙂 

Alan 

On 05/09/2022 at 17:27, 900SL said:

My Redcat 51 requires 56mm backspacing to the sensor.. its a petzval.

This Redcat 55mm or so backspacing 'requirement' is only if you want stars in focus and with the focus distance scale set to infinity. This will also allow you to focus on closer subjects as indicated by the distance scale on the scope, but for astro use this is not relevant. The Redcat is also marketed as a lens for terrestrial photography where the distance scale is useful, like on a camera lens. (Early versions of the Redcat had no distance scale markings anyway).

If you only have say 40mm 'backspacing' you can still focus the stars by setting the focus scale to a closer distance like 30m or something and you'll be fine. If you use much more than 55mm backspacing then you won't be able to focus at all. As long as you can focus the image with the Redcat, your 'backspacing' is automatically correct.

Unlike 'standard' astro telescopes where the lenses are fixed in place and you focus by moving the camera back and forth, the Redcat focuses by moving the complete lens assemblies back and forth so there is no fixed backspacing distance from the lens rear correcting elements anyway. 🙂

Alan

1 hour ago, Mandy D said:

Would it not take half of one rotation to visually move completely across Jupiter's equator, or have I missed the point, somehow?

Your statement is true, but doesn;t apply to the purpose of the discussion as to what amount of pixel movement due to planet rotation would be acceptable before image blurring is noticeable in the final stacked image. 😊

It;s equivalent to how much camera shake can you accept when taking a normal terrestrial image with a camera before the picture starts looking blurred. My saying half a pixels worth of camera shake during the exposure before noticeable blurring occurs assumes a sharp image subject to begin with.

Planetary images are blurred to begin with, due mainly to atmospheric conditions so the question is how much extra blurring due to planet rotation is acceptable. The initial figure given of around 3 pixels by CraigT82 is a reasonable figure it appears, and Autostakkert can align surface features quite well too, if they have moved a few pixels during the video.

My calculation using the image pixel size of the planet is valid, and if you input 3 pixels instead of 0.5 pixels then you get 2 mins video duration which is similar to what is commonly used. 🙂

Hope that helps Mandy D. 😃

Alan

13 hours ago, neil phillips said:

What most people dont consider is AS/3s ability to line up a 3 min sequence with minimal rotation occurring.

I admit I didn't consider AS3's effective de-rotation up to a limit by its grid alignment stacking process. 😊

Alan

On 03/09/2022 at 15:22, ObscuredView said:

Will my Zwo Asi224mc operate at the full usb 3.0 speed?

If the active extension is between the camera and the recording PC then no is the short answer. 😉

The circuitry in the extension cables will throttle the maximum transfer speed in order to allow them to work over long distances. You don't get something for nothing. 😊 A similar question was asked a couple of years ago on the forum as over a 15m USB3 active extension cable they were getting disk file transfer speeds of around 60MB/s. I think it was from an SSD but I can't remember. A 5m active extension cable was used instead hoping for higher speeds but it again gave only 60MB/s. Most likely all the extension cables used the same circuitry in their 'active' modules. Over a short USB3 cable I manage 200MB/s transfer from a mechanical hard disk.

Unless you're planetary imaging or transfering several gigabyte files over the active extension cable, you probably won't notice much drop in performance. Using a 1m USB3 cable I can get around 3Gb/s maximum from my ASI224 recording to a SSD on a mini PC at the mount, which is 375MB/s. 5Gb/s is the theoretical maximum for USB3 which will never be achieved in real life.

Alan

As your image is 250 pixels across Ags then 23 secs gives 0.5 pixel movement. 😊

Alan

I would actually say that anything over 0.5 pixel movement during the video would cause actual noticeable blurring in the stacked image. 🤔

A quick way to calculate the max video duration without worrying about angular resolution etc. is to measure the diameter in pixels of your Jupiter image. Lets say it's 300 pixels.

Circumference of Jupiter would then be 300 * PI = 942 pixels.

In 10 hrs (36,000 seconds) a spot on Jupiter's equator would therefore move 942 pixels

It will move 0.5 pixels in 0.5 / 942 x 36000 seconds = 19.1 seconds.

So it's proportional to Jupiter's image pixel diameter and the amount of pixel movement you're willing to accept.

Alan

Unfortunately backspacing has different meanings depending on what it's referring to.

The WO diagram for the Redcat 51 does show the image plane placed 54.7mm behind the rear plate of the scope. This is also  a common backspacing distance used for field flatteners and coma correctors as the spacing distance is critical for these items, and it conveniently enables a DSLR with T-Adapter to be fitted to the rear of such correctors, and the required 55mm spacing between the corrector rear and the image plane of the camera sensor is achieved.

The Redcat 51 'backspacing' figure of 54.7mm just means that if the sensor is placed this distance from the rear of the scope then the focus scale on the scope will read correctly. Useful if you have a DSLR with T-Adapter and when stars are in focus the focus scale will read infinity. If not at this distance you can still achieve focus but the focus scale will read incorrectly. Most astro scopes don't have a distance focus scale so don't quote an image plane distance, as it depends on what extras are attached to the scope.                

As you say, being Petzval designs, and as such a separate field flattener (with critical backspacing) is not needed, as long as you can achieve focus the stars should be corrected to the edges of the frame. 

Camera backspacing is not really backspacing, but is just the distance the camera sensor is behind the front mounting plate of the camera. Useful to know when you're adding extra spacing to achieve an actual backspacing distance required for a corrector etc.

Alan

Impressive image with plenty of detail. 😃 

Alan

1 hour ago, WilliamAstro said:

do you think it doesnt need this and it can just heat up via a power bank? because these seem to have long delivery

If you don't have the controller in circuit and directly connect the the dew heater to the power bank, it will run the same as if the controller is set to high power. If this isn't too warm then you can use it this way with no problems. 🙂

Alan

Amazon have a similar controller though it ends in a DC plug for £8.49

Aliexpress seem to have the same controller for £4.53 and free shipping from China.

Alan

2 minutes ago, Steve Ward said:

Thank for that Alan , you live and learn ... 🥰

No problem. 😉 The VirtualStore location isn't used much judging by the small number of programs that have entries in it. I can't see any advantage to it rather than just using \appdata\local\Registax 6\ but it perhaps allows 'automatic' program storage of user files without directly specifying the appdata location in the program itself. It's possibly a holdover from early Windows versions. 😀

Alan

The wavelet schemes are stored in

C:\Users\[Username]\AppData\Local\VirtualStore\Program Files (x86)\RegiStax 6

If you save and then load a scheme it opens up C:\Program Files (x86)\Registax 6 and displays them for selection but if you go to that location in file explorer they aren't there. The VirtualStore is a linked resource that behaves as if it's part of the main program. If the schemes aren't showing up when you go to load them then it's probably worth reinstalling Registax and see if that fixes it.

Alan

My replacement Autostar II arrived yesterday after being on back order from TS for over a year. I'd forgotten all about it.  I'll be more careful with this one compared to the original and triple check my extension cable wiring. 😊

Alan

55 minutes ago, tomato said:

Just got these before a cloud bank came over, RASA8/QHY268c, 10 sec exp, Gain 30, offset 30, cables arranged in a circle. There is a light house effect on the star but not sure if this is cable diffraction. Still some tilt on my sensor I'm afraid.

Thanks for those images Steve. All three show no asymmetrical flaring which is good and backs up Göran's images. I'll add them to the evidence given to FLO.

The 'dark' spikes seem to be an effect of the cable routing. I've been doing tests on different arrangements and so far the semi circular arrangement in front of the corrector plate seems to be the best with the least artifacts. I also tried fitting the semi circular loop level with the base of the camera to avoid running the cables down the side of the camera but any arrangement fitted further away from the corrector plate seems to add many small spikey artefacts all around the bright stars. Not sure why this happens.

Your tilt is quite noticeable unfortunately. Did you build one of the wooden tilt test jigs? I think they're likely a requirement with a RASA which has such a small depth of focus. Your stars on the right pointing towards the centre indicates the camera right side is too far away. I believe you have the Artesky filter holder which is a single piece so can't make it shorter. The Starizona one I have on order from FLO incorporates a removeable 5mm spacer which I thought would be useful if the distance needs to be reduced. 

Comparing the size and shape of your elongated stars compared to the first RASA I had which needed a 0.5mm spacer yours look to be greater than 0.5mm out on the right compared to the left. Hope you can get it sorted.

Alan

3 hours ago, tomato said:

Apologies Alan, for not responding to your request.  I’ve been dealing with a serious tilt problem on my RASA8 which I think I have now resolved. 
So if it’s clear tonight I’ll point it at Deneb and take some subs before I start my imaging run.

Steve

That's OK Steve. If your Deneb images are similar to Göran's Arcturus then it should provide solid evidence that a batch of current RASAs have a problem which must be addressed by Celestron who seem to be dragging their feet with the issue. 

I had to set the camera tilt very accurately on the test jig before putting it on the RASA. The first RASA I had to add a 0.5mm spacer to avoid elongated edge stars  while the second was good without it. Edge stars pointing towards the centre means the spacing is too great, the opposite of what refractors tend to indicate. Getting the same tightness on the locking ring is critical to maintaining the spacing distance too.

Also I found that over an imaging run one side of the image may start developing elongated stars and a refocus fixes it though the change in focus isn't enough to make the central stars appear out of focus. I tell SGP to refocus every hour which helps. 🙂

Alan 

Hi Roger,

I replied to another post concerning fps and settings using Firecapture and I've repeated the relevant points below and added others applicable to colour cameras. It applies to any capture software.

Don't use binning as the image of Jupiter will be quite small and you want to get as much detail as you can.

As Jupiter rotates relatively quickly limit your videos to 30 to 45 secs duration hence the need to get your fps as high as possible. 

Frame rate is set automatically to be as high as possible. Frame rate will be limited by the processing power of the computer running Firecapture and the camera itself, but is initially  determined by the exposure duration. How many exposures will fit in 1 second. It's the reciprocal of the exposure. An exposure of say 10mS or 0.01 seconds gives a maximum frame rate of 1/0.01 fps which is 100 fps. A 5mS exposure gives a maximum of 200fps.

You won't achieve these maximum framerates if the full sensor is used as the camera will not be able to process the full frame data fast enough. A smaller ROI big enough in which to fit  Jupiter will enable higher framerates to be achieved, up to the exposure determined maximum, though the camera may max out at 250fps or similar where an even smaller ROI doesn't help.

It's only the height of the ROI that determines the frame rate available, so the ROI width can be left at maximum if you wish, for no loss in fps. This means you can have a wider image to get some of Jupiter's moons in thepicture, if your camera is orientated correctly, without causing a reduction in fps.

Don't enable gamma when capturing the video, leave it unticked or at 50 which is off anyway. Gamma processing each frame takes considerable processing time so your frame rate may suffer. You can easily gamma adjust the final image later in PS or whatever you use.

Aim for an exposure around 5mS if possible, and adjust the camera gain to get the histogram maximum around 70% of full. Having a very high camera gain is not a problem and will benefit from lower read noise. Although the preview may look very noisy, once several thousand frames are stacked in post processing this noise will disappear.

Check that the histogram peak corresponding to the 'black' sky background is not butted up against the left edge of the histogram and that the left side of the peak is just visible. Set the camera gain first, and then the camera offset to set the 'black' background peak position on the histogram.

Don't enable debayering while capturing the video as that will drop the framerate quite a bit. Your stacking/processing software will do the debayering. Firecapture lets you debayer the image for previewing but automatically disable it while capturing the video.

Also, you may as well use 8-bit capture and enable the 'high speed' option in the Firecapture camera setup panel if it's available. This will get the highest framerate. 'High speed' uses less bits for conversion like 9 or 10 bits which you might as well use if you're saving in 8-bit.

Stacking at least 100 8-bit frames will gain you around 4 extra bits of image depth so will be equivalent to a 12-bit image. This is only if noise is present in the individual frames, which there will be. Here's the theory behind this by Craig Stark The Effect of Stacking on Bit Depth, which is an interesting read.

If you have the USB2 ASI120 then you may struggle to get high frame rates, compared to the USB3 version.

Hope this helps. 😀

Edit: I forgot to mention about using the optimal focal ratio to maximize your potential image resolution. The optimal focal ratio is 6 x the pixel diameter in microns for a colour camera and 3 x the pixel diameter for a mono camera. For your ASI120MC this means optimal focal ratio is 3.75 microns x 6 = f22.5

So use a barlow or powermate on your setup to get somewhere close to this number. 

The maths behind this is explained clearly in this article posted by a member of the forum. It's in Dutch but Google translate works very well. 😀

For focusing I focus on a nearby star with a bahtinov mask though others have focused using a mask on Jupiter's moons.

Alan

1 hour ago, gorann said:

The one with mask looks rather good so I suggest you just make the best out of the RASA you have until you get an replacement. Here are the raw fit files.

Cheers, Göran

2022-08-29-2022_1-CapObj_0001.FIT 49.77 MB · 0 downloads 2022-08-29-2023_9-CapObj_0001.FIT 49.77 MB · 0 downloads 2022-08-29-2024_9-CapObj_0001.FIT 49.77 MB · 0 downloads

Thanks for the fits files. Yes, I'm happy with the masked results until the issue is resolved. 🙂

Alan

10 hours ago, gorann said:

Hi Alan

I did what you asked for last night. I went for Arcturus, the brightest star in the northern hemisphere. Here are three single 1 second frames at gain 100 with an ASI2600MC. So, left edge, center and right edge of the field.

As you see there is none of the flares you see, so it is most likely a problem with the current RASA batch.

Cheers, Göran

Thanks very much Göran, that does confirm that some newer RASAs have a problem. Can you share the raw fits files for these three images, so I can send them to FLO who can then use them in their discussion with Celestron about the current RASAs.

Had two clear nights the last couple of days and did an hour or two on various targets with and without an aperture mask. Here's a comparison with M33 given a quick process in Startools with no star manipulation, sharpening decon. or noise reduction. The image without a mask doesn't have a correponding flat frame I'm afraid so is a bit uneven brightness. These show that even modest brightness stars show the flares quite noticeably with no mask. The one with an 180mm mask is much better with just the corners and extreme left and right edges showing some flaring.

RASA 8, ASI2600MC, 180mm aperture mask, 142 x 60s subs 🙂

RASA 8, ASI2600MC, no aperture mask, 110 x 60s subs 😟

Alan

37 minutes ago, Rustang said:

Thanks, is this better than capturing in 16-bit in Firecapture then?

You'll generally double the frame rate capturing at 8 bit compared to 16 bit which is an advantage. Planetary type imaging doesn't involve large stretching to the black areas of the image like DSO imaging so a high bit depth isn't so necessary. I doubt you'll see any difference in the final result between a 16 bit image and an effective 12 bit image resulting from a stacked 8 bit capture.

Try both methods and see if you can spot any difference. 😃

Alan

4 hours ago, gorann said:

Thanks Alan,

so do you say I should go for 60 s subs or less? In the winter I can get 20 hours with my dual rig in a night so then I would spend days stacking 1200 subs (not to mention the harddrive space needed). Or should I run it at gain 0? I do not feel I have much problem with the stars and I do have to stretch the data a lot sometimes to get to the faintest stuff. But I never made any calculations like you have.

CS, Göran

As vlaiv has mentioned in other topics, swamping the read noise value by a factor of 5, by the sky background noise value, makes the read noise contribution to the image insignificant. If the ASI2600 RN is 1.5 e- (electrons) and you expose long enough so that the noise from the sky background is 5 x 1.5 e- = 7.5 e- then the combination of read noise plus sky background noise is 7.64 e- which is no different in reality to just the sky background noise alone.

At this point you may as well start another exposure as the stacked S/N of 10 x 3min subs is then the same as 30 x 1 min subs. The shorter subs of course will have less star bloating.

The sky background ADU for 5 x RN swamping is (RN * 5)^2 / gain + camera_bias for a 16 bit camera

= 230 + camera bias average value

The gain here is the e-/ADU gain taken from the supplied camera graphs which is 0.245 e-/ADU at Zwo gain value 100

The bias value includes the default offset value of 50, which for me is 503 ADU so 230 + 503 = 733 ADU sky background value required.

The sky background value is the median value of the image for an image not dominated by nebula, or hover your mouse over the image background and read off the ADU value.

The downside of course is more storage, and time needed to stack the subs as you mentioned. 🙂

Take a 60s test sub in the middle of the night with no moon and see what the sky background value is. If it's over 733 ADU then 60s is a good exposure to use. You can use 90s or 120s if you don't want so many subs, but I think less than your current 180s  would be beneficial.

I would stay at gain 100 as that is where the HCG (high conversion gain) mode is enabled which greatly reduces the read noise, for little loss in dynamic range.

These exposures are for no filter imaging with the ASI2600. With an IDAS NBZ the 733 ADU target value is the same, but much longer exposures will be needed to achieve this value.

Hope that helps Göran. 😊

As your sensor chamber may not be airtight which is causing your problems, filling it with argon may likely be a temporary solution until it leaked out. Worth a try though if it doesn't cost too much. 🙂

Alan