Well my first few nights into Mono imaging with the 2600MM went really well , sort of……,
Clear nights
Chose NGC 253 Sculptor Galaxy for Broadband ( Antlia LRGB ) 90 sec subs in Bortle 8 ,4 hours worth, Gain 100
Chose NGC 7293 Helix for Narrowband ( Antlia 3nm Ha Oiii Sii ) 180 sec subs under Bortle 8 , 12 hours worth , Gain 100.
Ra and Dec balancing was easy ( only a slight adjustment from my 2600MC )
Camera and filter wheel operating perfectly
Camera temp stable at -10C
Subs looked great
Guiding was great 0.45 to 0.60 total over most nights
Captured Cal frames ( Bias and Flats ) similar procedure to my 2600MC
Culled all the bad subs in ASTAP
Now ……
Registered subs in DSS, chose best sub for reference frame for each channel
Stacked subs in DSS using a best reference frame ( and yes I unticked fits digital development when using a Mono camera )
Loaded each channel into Startools via Compose
Both Broadband and Narrowband auto stretched images on all individual channels had a small checker board matrix pattern across the background of the image ( see attached ) Never ever saw this with my 2600MC ???
Tried using different Alignment Transformation algorithms Bilinear , Bisquared , Bicubic etc… but no change
Tried using both Standard mode and Intersection mode for Stacking result , again no change
Tried stacking with lights only ( No Cal frames ) again no change
Tried stacking 1 night only ( no use of Groups or reference frame ) again no change
Then I noticed in Results tab, I had the box ticked that says “Align RGB Channels in final image” , so unticked it , again no change
I’m confident it’s a stacking issue but tried various settings with no change
I’d prefer not to use another stacking software as my 2600MC has performed flawlessly with broadband and narrowband imaging for many years now using DSS
Are there folk who use the 2600MM camera and use DSS for registering and stacking
I’d certainly welcome any advice right now
I won’t be using the camera again until I nail this issue
Are you happy to bundle them up and send via wetransfer or similar? I can try them in APP and see if I get a similar result, I know you want to keep using DSS but that would at least confirm if the basic data is good or if there is a problem with the cam output.
Edit, what offset are you using, I use gain 0 (And occasionally gain 100) and offset 50.
My guess - your capture software is set to OSC and/or storing a bayer pattern so DSS interprets them as colour & applied the bayer pattern. Go into the settings in the capture software & be sure colour preview & store bayer pattern are disabled. You will probably need to convert your current subs to mono - not sure about that.
Are you happy to bundle them up and send via wetransfer or similar? I can try them in APP and see if I get a similar result, I know you want to keep using DSS but that would at least confirm if the basic data is good or if there is a problem with the cam output.
Edit, what offset are you using, I use gain 0 (And occasionally gain 100) and offset 50.
Thanks Paul
Gain 100 ( offset 50 ) as per my post
The best I could do is Zip the files up into 9 x 1GB Zip files ( Ha Oiii Sii Lights Flats Bias ) and send them over 2 or 3 emails
My email server is limited to 33MB transfer so I’d have to use my wife’s gmail account , she’s out at the moment
Let me know
Cheers
Martin
As suggested by Paul, worth checking with another stacking software to eliminate the hardware.
Meantime, are you using the latest DSS version?
The one on the official, but deprecated, website is v.4.2.6.
A small team is still updating and maintaining DSS, hosted on GitHub, latest v.5.1.3.
If you haven't done already, try stacking using the latest version.
Thanks
That’s my last resort
The latest version of DSS still has bugs , I check the site each day , plus I’m a member too
My current version is at least stable and proven
Cheers
Martin
My guess - your capture software is set to OSC and/or storing a bayer pattern so DSS interprets them as colour & applied the bayer pattern. Go into the settings in the capture software & be sure colour preview & store bayer pattern are disabled. You will probably need to convert your current subs to mono - not sure about that.
Cheers,
Mark
Thanks Mark
I bench test all my gear before using it at night
Here’s my written procedures below ……
APT Camera Selection
Every time you change from ZWO2600MC to ZWO2600MM you have to change the following settings in APT obviously once camera is connected !!
Connect Camera ( Shift / Connect )
CCD: Ascom Camera
2600MC , check Color FITS preview ( De Bayer ) box
2600MM , uncheck Color FITS preview ( De Bayer ) box
Then OK.
Ascom Camera Chooser
As per normal ASI Camera (1)
Properties
Correct ZWO camera should appear
Then set Gain etc… OK.
Tools Tab ( top right )
APT Settings Tab
CCD Tab
Change Camera name as required
Then press Reset image ID button
OK
Important !!!
After each camera change , you must shut down APT and restart APT to enable camera change to be locked into program
The subs were definitely mono ( not Colour ) during capture as I’ve been using my 2600MC for 3 years and could tell straight off the bat they wee mono
But then again I could be missing something, you never know
I’m leading towards an alignment stacking issue in DSS
Cloudy nights have a few leads on this issue but like everything, it’s trial and error
Paul has offered to review my subs which is a priority at the moment
Ah, I saw the gain but not the offset, same figures I use with both of my cams.
If you send via Wetransfer you don't need to email the file, it is a straight file transfer service.
If you wanted to check against Astro Pixel Processor you can get a 30 day trial license for that for free. APP ignores bayer information in FITS headers and only debayers if you select to do so so if that is your problem it will show it by integrating normally straight away.
I recall someone else had this issue recently (If that is what it is) but cant recall who it was, and they found some software to rewrite the FITS header information and remove the bayer info.
Ah, I saw the gain but not the offset, same figures I use with both of my cams.
If you send via Wetransfer you don't need to email the file, it is a straight file transfer service.
If you wanted to check against Astro Pixel Processor you can get a 30 day trial license for that for free. APP ignores bayer information in FITS headers and only debayers if you select to do so so if that is your problem it will show it by integrating normally straight away.
I recall someone else had this issue recently (If that is what it is) but cant recall who it was, and they found some software to rewrite the FITS header information and remove the bayer info.
We transfer want you to sign up for 6 months at $28 a month
They offer a free 2GB service but nowhere near enough
I might post on the DSS forum and APT forum and go from there
My last resort would be to try another stacker software
Cheers
Martin
PS Unless someone has had my issue in the past year or so on this forum ?
Found it. Second last post on this thread, with potentially the same issue you are having. f4w2hdudoc software to edit the FITS header and remove any bayer matrix info incorrectly written there.
With APP it is the other way around, you have to remember to tick the debayer box each time if you are using OSC data or it stacks as mono.
Found it. Second last post on this thread, with potentially the same issue you are having. f4w2hdudoc software to edit the FITS header and remove any bayer matrix info incorrectly written there.
With APP it is the other way around, you have to remember to tick the debayer box each time if you are using OSC data or it stacks as mono.
I replied to his post below !!
I didn’t forget to change APT settings from OSC to Mono so my fits files read Mono whereas before when using the 2600MC they read Color
And in DSS I unticked the fits box for colour cameras , the Bayer filter symbol disappeared
I’m sure my issue is not the same as g—-day
He didn’t post an image of what his mistake looked like ?
I’ve just sent a post on the DSS forum , hopefully some feedback tomorrow?
Martin
Does the effect appear with only a handful of subs stacked in DSS? If so do you want to send me the same handful of subs (And maybe 10 bias frames, and you use the same ones) and we can see if APP makes the same out of it? Keeping it to a handful of subs would make it feasible to send via Wetransfer.
Does the effect appear with only a handful of subs stacked in DSS? If so do you want to send me the same handful of subs (And maybe 10 bias frames, and you use the same ones) and we can see if APP makes the same out of it? Keeping it to a handful of subs would make it feasible to send via Wetransfer.
I’m away for a few days so I’ll test a smaller batch on Monday / Tuesday
Let you know
Thanks
I think I’ve stumbled across the problem with checkered pattern in my images
Here’s an image of my flats with histogram adjusted to expose my issue
I’ve been using an old white t shirt stretched over my Newt and a Huion dimmable light panel for years with my 2600MC , no issue at all
Unfortunately the 2600MM is so damn sensitive it’s picked up the pattern of the t shirt in the image from calibration
The issue doesn’t present itself until you stack loads of data with calibration frames ( flats and bias ) I tried stacking just 20 or 30 subs with 10 flats and 10 bias , then an auto stretch and you can just see a very faint pattern
The problem exacerbates when you stack multiple nights of the same filter too
I tried no calibration frames and the background was clean as whistle ( apart from Vignetting)
Any ideas as a substitute for the white t shirt ?? maybe just use the light pad with a opaque piece of plastic ??
What sub length are you using with the shirt? I have found the 2600 will take good flats down to around 0.5 seconds exposure, so as long as you can keep above that with the panel only it should be OK.
So being on a high with confidence that I’ve finally nailed the issue , I thought I’d stack Ha , Oiii and Sii data with out Cal frames and then load into Startools via Compose and cross fingers no pattern
You guessed it , after an AutoDev stretch , background has checkered pattern again
So I just tested each data set individually in Startools and yep checkered pattern again but what was interesting the Ha and Oiii images had the checkered pattern running NSEW but Sii had it running at 45deg corner to corner
Buggered if I know what to do next
I captured 2 nights of Ha , 1 night of Oiii and 1 night of Sii
If I stack 1st night of Ha without calibration, image is perfect
If I stack 2 nights of Ha without calibration image has pattern NSEW
If I stack 1 night of Oiii without calibration image has pattern NSEW
If I stack 1 night of Sii without calibration images has pattern at 45 deg corner to corner
In DSS I’m using a reference frame to align the separate channels, however individually each channel still has the pattern ???
Doesn’t make any sense at all ??
Faulty sensor ??
Frost on sensor ??
Any further suggestions other than try another stacking software??
I do use ASTAP for reviewing subs only , does anyone have procedures and recommended settings for registering and stacking in ASTAP using Ha , Oiii and Sii or LRGB mono data sets
Startools has a brief guide using ASTAP but how do you align your stacks so they are exactly the same size and alignment. Startools Compose requires stacked data sets identical in size to be able to load and process
I've never seen a definitive answer to the odd cross hatch pattern in images, and I've only experienced it once or twice and I believe it went away with more integration time (i.e. low signal so stretching the bejesus out of the master). I dont think at this stage faulty or frosty sensor is the likely culprit.
I think I'd read that its usually caused by incorrect debayer settings in stacking, or shot or dark current noise stacked from non dithered frames.
I'd suggest the following if you havent tried these yet:
You dont mention dithering or the use of dark frames. If you dont dither, try dark frames as part of your calibration set. I'd always recommend dithering btw. Personally I dither ~15px every sub, and use dark frames in calibration. Costs nothing and moar calibration frames are always good. Remember, you can leverage a dark library for around a year of imaging.
Just checking you are using offset 50 with gain 100? A low offset and stacking in a product like DSS that doesnt have pedestal subtraction routine may leave artifacts subject to the signal level.
I suspect it might be that you're not 'swamping' the read noise with your sub length. Assuming you're using the f5 newt in your sig, with 3nm filters in a bortle 8 3mins may not be enough. Granted I'm at f7 on my rig which is quite a bit slower but I never go under 10 min subs on the antlia 3nm at unity on the 2600, and even then my mean adu on an average sub on a reasonably faint target is 650-700 with the Ha. Given the bias mean adu on a 2600 at gain 100 is ~505adu theres not a lot of net signal in a single sub. Hard to see from your screenshots, but it does look like the hatching pattern is significantly less noticable in the high signal areas of your picture...
Going to 5 mins at f5 should be sufficient? That, and dithering at least 12-15px might be worth a try? Best of luck solving this! I'm sure you will!
Hi Adam,
I’ve been dithering for years and yes your probably right about exposure times but this is my first venture into Mono so step by step approach with exposure and gain
I’m getting some encouraging results using ASTAP to calibrate, align and stack this data set
A few folk are providing some ASTAP tips on various other forums and looks like I’ll be ditching DSS, at least for Mono imaging. I’ll probably still use DSS for OSC work as it’s performed well for years both DSLR days and the last 3 years using my 2600MC.
A few more tests with ASTAP and Startools over the coming week
Thanks
Martin
PS My flats are fine, however the t shirt has to go anyway , a bit antiquated. I’m buying some good quality 3mm opal acrylic differ to sit between the OTA and light panel , just to disperse the light more efficiently and have better illumination control.
