Indeed. “Walking noise” is caused by warm pixels and drift during the whole capturing session. Jerry described the way how the warm pixels are removed from the individual calibrated light frames by CosmeticCorrection. This is especially useful when no dithering is applied during capturing.
Bernd
Bernd, I think you’re misunderstanding what Jerry was recommending. He specifically mentions hot and cold pixels (aka salt and pepper noise), which usually take on the more extreme values, not “warm pixels”. Cosmetic correction is good for that and for removing sat and plane trails because the resulting pixel values become outliers statistically. Fixed pattern noise (FPN, one of the causes of walking noise) is not hot and cold pixels, and as far as I can determine no one seriously recommends using cosmetic correction to remove it. It doesn’t respond well to CC because the pixels are generally not statistical outliers. Yes it is possible to reduce the appearance of FPN by using CC but it will also harm your image’s SNR because you begin rejecting vast numbers of signal pixels as noise. There are numerous threads on CN by AP vets that spell this out, here is one of many:
The ASI1600MM is notorious for producing FPN and walking noise when dithering is not used (refer to CN again). Because Jerry uses a 1600 and doesn’t use dithering explicitly, I was wondering whether there was some other process he was using that he simply didn’t mention, thus my enquiry. I doubt that his use of CC is having much of an effect on reducing any FPN that may exist in his uncalibrated subs, so I assume his use of “implicit dithering” by taking subs over multiple sessions, recentring after meridian flips, etc., plus mixing the 1600 subs with those of the 183, is enough to keep it at bay.
So I owe you a thank you Jerry; I would never have guessed that a “no dither” regime was possible with a 1600. The loss of imaging time due to dithering can be significant, especially so if you’re using large guiding cadance, and even more so if you dither every frame as some imagers do. And “no dithering” dual setups become considerable more efficient because there would be no sub corruption due to dithering. I might just rethink a dual imaging rig again.
Thanks for this thread Xsubmariner.
Thanks Ross for your elaboration on FPN. I was not aware that the 1600s are reputed to be notorious for this. I simply have never noticed any aberrations in my images that would indicate any walking noise issues. I do know that my ASI183mm has a severe case of amp glow at the right edge of the image. Fortunately when I combine images from the 1600 and the 183 the amp glow is a non-issue, for the reason that the FOV of the AG12/ASI1600 is smaller than the FOV of the NP172is/ASI183, so I am not using the right edge where the amp glow is located. By design of course. (he he)
Back to the 1600, many of my images only use subs from the 1600, and I don’t see any walking noise there either. Certainly combining images could mask this, but I have never seen it in the pure images from one or the other, which I do always look at before Integrating the combined set of Registered images. Maybe I’m lucky that my 1600 does not exhibit FPN?
Also many of my images involve only 1 or 2 sessions which would not produce meaningful dither. Plus my centering is usually within 1 or 2 pixels of dead center from night to night. Having a fixed obs really helps.
I don’t think this can harm the SNR since the CC routine only lets you reject up to 10,000 hot pixels, which is a tiny fraction of the 20m total pixels.
Hello Jerry.
I should have used the term fixed pattern noise rather than walking noise. If your PA is accurate I doubt you’ll see walking noise, but my understanding is you’ll see the FPN in the 1600 when you integrate the subs into a master and then stretch the master. You won’t notice it in single subs as it’s among the background noise, but because it is similar in nature to signal (rather than noise) no amount of integration time will reduce it.
I don’t think this can harm the SNR since the CC routine only lets you reject up to 10,000 hot pixels, which is a tiny fraction of the 20m total pixels.
Try adjusting the sigma and level controls rather than the quantity control; you can reject as many pixels as you wish, including many millions. But yes, if you are only rejecting 10,000 pixels I doubt you are rejecting enough FPN pixels (if any at all) to affect your SNR.
Also many of my images involve only 1 or 2 sessions which would not produce meaningful dither. Plus my centering is usually within 1 or 2 pixels of dead center from night to night. Having a fixed obs really helps.
That’s intriguing, and good to know too. Perhaps FPN is only really a problem on faint targets? Anyway, thanks for info on your dual setup and processing.
I tried detecting an exoplanet using the transit method and my first attempt used a piggy back guide scope. Over the course of the 5 hours of 30 second images the field drifted by about 30 pixels as a result of flex and possibly mirror flop.
The resulting graphs of relative magnitude had some slow variation that made the detection uncertain, the experts called it ‘red noise’ and it was because of the movement. Is this what you mean by walking noise?
Next time I used an OAG, no drift and the transit was visible.
Guy’s this thread is a great read for me. Picking up on the likely consequences of dual operation and the requisite preemptive actions needed to minimise them is great. I can see that I need to put more thought into the regime that I follow for sequencing my sessions. Thank you for your input, it is important to me at this relatively early stage of learning.
Hello Ross
A correct ImageCalibration is the prerequisite for removing part of the cold, warm and hot pixels.
CosmeticCorrection is not at all appropriate for removing sat and plane trails. These artifacts are removed by pixel rejection in the ImageIntegration process. CosmeticCorrection shall be used to remove remaining rests of hot, warm and cold pixels. These remaining rests cannot be removed completely by ImageCalibration because the pixels in question do not behave linearly.
You asked about problems with “walking noise”, and not “fixed pattern noise”. Consequently my response referred to “walking noise”.
I am aware that dithering is the only measure to remove fixed pattern noise. If this is a problem with your camera, you will have to dither.
Bernd
Thanks for your reply Bernd. Yes I agree with you on 1, 2, and 4, and thank you for correcting my understanding of sat/plane trail removal. I’m sorry to say I’m still not yet convinced that Jerry reduced any possible walking noise in his image by using CC to remove less than 0.06% of the image pixels though, but I may well be wrong of course.
It might really depend on the camera which is used whether a No dither / CosmeticCorrection approach is successful or not. However, another probable possibility for issues is a not correctly performed ImageCalibration. E.g. there are “established” tutorials that recommend to calibrate the dark frames with a MasterBias or superbias. This is a nonsense, it has to be done differently.
Bernd
Indeed, we have nothing in my images to confirm whether on not CC has any effect on FPN or walking noise. Reason: there is no FPN in my 1600 images. So not all 1600s exhibit FPN, mine being one that does not. See attached link to a sub I took last night on the 1600 with no moon and good seeing.
https://www.dropbox.com/s/1atoda5ma0p8ps8/NGC2366%20Barred%20Irregular%20Dwarf%20Galaxy_0220_t0180_-16C_1x1_R_0001-2.fit?dl=0
There is no FPN in this sub.
Currently I run a setup with two cameras on two telescopes with autofocusers and filterwheels. I tried running two incidents of SGPro but this proved to be very unreliable. One of the cameras is an Atik 314L+ and the other an SX Trius-694 Pro, and this seems to create an issue. While the Atik will work, the Starlight Xpress camera starts to loop and hangs SGPro. I use an HP laptop powered by an Intel i5-8250 4 core processor with 8Gb of ram, so it should be capable enough.
The solution has been to run the main camera, SX filterwheel, focuser and the mount using SGPro, and the Atik and filterwheel using Nebulosity V4. This is not really satisfactory as Nebulosity does not have an autofocus routine and it has no idea when a Meridian flip is going to occur.
So for me the two camera version of SGPro cannot come soon enough, but it may be worth checking that Atik and Starlight Xpress cameras will work together. They are both very popular makes but I understand this ‘incompatibility’ is not unusual. It may be worth noting that I am unable to use N.I.N.A. or APT for the Atik 314L+ as both cause the SX Trius-694 to loop with SGPro which then hangs requiring a computer reboot. Nebulosity causes no such issues.
In general SGPro is a really excellent program and I’m very pleased with it. There are occasional little niggles, but I cannot imagine using anything else now.
Hi Nicholson,
I am also running 2 instances of SGP with different camera/telescope configurations:
ROR Observatory- PC runs SX36/FW/Foc/MX/10"RC/roof control as Master SGP instance (1), with ZWO1600/FW/Foc/Rotator/GTF81 as Slave SGP instance (2).
Dome Observatory- PC runs ATIK383/fw/Foc/MESU/TS130/dome control as Master SGP instance (1), with ZWO071c/Foc/AA130reduced as Slave SGP instance (2).
Both of these dual systems now run fine after some minor corrections to SGP configuration settings. I currently have not attempted to run the SX with an Atik camera on the same PC in a dual instance setup so am unable to say if there is a driver conflict between the 2 camera makes.
Might I suggest you scrutinise the SGP configuration settings for each instance carefully to ensure you are not creating the problem between the cameras, if each camera works ok within a single SGP instance you are more likely to find the problem lies in a configuration setting.
For example; a problem I found with my Dome observatory dual instance setup where the master instance ran everything fine. When I tried to start the slave system run I was informed “Warning - Error connecting to observatory! - Sequence attempts to auto slave the observatory on sequence start - proceeding will not allow slaving of the observatory to the mount. Would you like to continue anyhow YES/NO(in box)”. Every time I selected YES the message was replaced by "Error connecting to No Observatory! Object reference not set to the instance of an object OK(in box). Selecting OK put up the original warning and so I found myself lost in a loop between the 2 messages. At this time the atmosphere in the room was getting rather blue, as I repeatedly attempted to resolve the problem by repeatedly checking the slave profile and reloading it to the slave sequence. Now late at night I gave up grateful that nobody was with me in the control room. My frustration was the slave profile didn’t have an observatory selected.
The next day I found the problem, while “No Observatory” was indicated in the equipment profile, when I selected the Observatory slave settings box the configuration settings for my Shelyak dome controller opened. Deleting the dome controller settings, saving and reloading the profile resolved the issue.
Lesson learnt:- reconfiguration of existing profiles for a different use can be quick but has its potential pitfalls where lower level settings are missed. I would try rebuilding your profiles for each instance from scratch just to ensure you are not copying over unwanted settings.
Good luck and clear skies.
I have image scales of 0.87 and 2.10 and my question is how would the guiding be controlled? This might be a dumb question, but I’m thinking that my 0.87 scale scope would be guided thru phd2 and the 2.10 scope would overly correct in respond to the corrections for the larger scope? Thanks for any help.
Gunny01, you’re thinking about this the wrong way. If your guiding is good and there is no flexure between the scopes then guiding corrections on one scope will have no adverse effect on the other scope. Since both are riding on the same mount the scopes should also move the same in tandem.
And besides that, the 2.1 image scale is far more forgiving than the .87 image scale, meaning even if the .87 scope moves slightly differently in relation to the 2.1 scope (flexure) the difference in image scales will mean that you won’t be able to see that different movement in the 2.1 scope. In fact, I would guess that you might even be able to use a small dither on the .87 scope and you won’t be able to see that small movement in the 2.1 scope, even if the dither takes place while the 2.1 scope is still in the middle of an exposure.
So as long as everything is reasonably rigid and there is no flexure between the scopes just guide through the .87 scope and don’t worry too much about the 2.1 scope.
I’m setting up a dual camera rig and finding this to be an important feature to have when shooting narrowband on both rigs. If both are taking 10+ minute exposures and they fall out of sync you can get in a situation where every exposure on the secondary rig is lost. I’d like to stay with SGP since it has served me well for the last 3 years but I’m not sure I can use it with this setup. I know it’s been on the list for a while… any update on where it sits in the list of features to be rolled out?
I would also be interested
I have just recently set up a two camera rig. A 152mm f/8 with a ASI2600MC-Pro, EAF and EFW and on a GT81 IV running an Orion G26 OSC and EAF. This is plugged into a Pegasus UPB v2 with a single USB 3 wire running to a Small Windows 10 PC that Is attached to the mount tray that I access wirelessly from the warm confines of my basement lol. I have multiple profiles setup based on what is doing what that evening and granted for me at least it is all new and a learning process but I have been able to take subs out of both rigs at the same time on the nights I have not had clouds and snow. I fire up the mount and connect it with CPWI tp the PC and then fire up PHD 2. If I feel like I need to sync I will startup the Orion software as it has a video live mode and will center on a star, close out of this and start up SGP. Use the big scope profile and connect camera, EAF, EFW, mount, and Pegasus environment sensor and start camera cooldown. I then start up a second instance of SGP and start the camera, EAF and environment sensor and start the cooldown as well. I do not use dither in this mode but I have set up profiles to use dither if I am only using one scope or the other. These cameras both use the Sony IMX571 CMOS chip and have no issues and run with low noise and dithering not as important maybe, wishful thinking but I don’t see any hot or cold pixels in what I have so far collected photons for. The only issue I have encountered is with the two focusers and I have to figure out if it is user error or a “feature” and I say that in that if I touch nothing the two versions of SGP run and I have the refocus routine set to every .5 C in change and filter change and nothing else checked and the one does that and the other one will do it between every frame even though it is set the same. So to get around this I have set the big scope to refocus every 6 frames. I have run this rig quite a bit over couple of months and will be waiting for 4.xx that will incorporate dither for two cameras and optical tubes on one mount.
I have been thinking about dual cameras too, using one for long-exposure narrowband and the other for shorter RGB on the same target. Presently, this is running on two separate rigs but I can foresee that the logic to dither on a single rig causes a headache, not matter which way you do it. If the exposure durations are quite different, logic would suggest to synchronize the dither with the longer exposure and waste a few shorter frames… but then, say dithering every 3 Ha frames, I would only be dithering every 15 RGB frames. Putting it the other way around would mean waiting for the Ha frame to complete before dithering the RGB. It is messy, whichever way you do it and the only solution that is easy (but not particularly useful) is to have synchronized exposure durations of the same length.
Did anything for dual cameras or rugs get incorporated into SGP v4?
No nothing yet on dual imaging trains. Not sure what you mean by rugs.