Page 1 of 1
noise grid
Posted: Thu Aug 04, 2016 10:59 am
by alacant
Hi everyone
Can anyone troubleshoot this? Since I've switched to dithering, there's a grid pattern appearing. I've tried loading with
not bayered white balanced and with
bayered not white balanced as well as ISO 800. No difference.
DSS of 2 minute snaps with bias and flat. ISO 1600. Canon 700d modified. 760mm telescope dithered with APT dither 5 and PHD2 dither 1 giving around an 8 pixel dither. Auto Dev>Wipe>Dev redo global stretch.
This happens with both random and spiral dither. ST denoise does a good job of removing most of the grid especially if I bin to around 35%, but I'd like to get rid of it. I'm very impressed by the noise reduction the dither brings -and being able to get rid the pixels the canon darks introduced- but really would like to perfect this and lose the grid. Any pointers most gratefully received.
TIA and clear skies,
Steve
-
- grid.JPG (183.8 KiB) Viewed 5769 times
Re: noise grid
Posted: Sun Aug 07, 2016 6:48 am
by admin
Hmmm... That is really rather odd...
I'm inclined to say the debayering method/settings used while stacking are incorrect.
Good to hear using PHD and dithering is working out for you though - it can really make a big difference!
Re: noise grid
Posted: Sun Aug 07, 2016 11:05 am
by alacant
Hi
Thanks. I used DSS with 20 lights, 20 flats and 48 bias. DSS recommended kappa-sigma, median kappa-sigma and median kappa-sigma respectively. I've a feeling this is wrong; doesn't the kappa sigma thing remove data? For flats and bias I think we want to retain data...
Not an expert. I've posted to the DSS list too but if anyone here...
Cheers,
Steve
Re: noise grid
Posted: Sun Aug 07, 2016 10:17 pm
by admin
Have you tried stacking w/o the bias frames and see if that gets rid of the pattern?
Kappa-Sigma is merely one of the ways DSS can try to determine which pixel is "the truth". It should really be no more destructive/valid/invalid than any other method.
Re: noise grid
Posted: Thu Aug 11, 2016 2:12 pm
by alacant
Hi Ivo, everyone
I found it. All credit to you for setting me along the right lines. In DSS, there's this:
https://drive.google.com/open?id=0B_uUt ... XYyc2tHUnM
Noise, yes:
https://drive.google.com/open?id=0B_uUt ... XdDekNyaUU
but random.
Guideline works-for-me only: toggling the first two options
bilinear or
ahd removes the grid, visible after the second st stretch
Thanks again and clear skies,
Steve
questions:
* should we use
develop rather than
stretch?
** does anyone have a one liner for bayer? Google gives loads of technical stuff but nothing too readable...
Re: noise grid
Posted: Sun Aug 14, 2016 12:50 am
by admin
alacant wrote:Hi Ivo, everyone
I found it. All credit to you for setting me along the right lines. In DSS, there's this:
https://drive.google.com/open?id=0B_uUt ... XYyc2tHUnM
Noise, yes:
https://drive.google.com/open?id=0B_uUt ... XdDekNyaUU
but random.
Guideline works-for-me only: toggling the first two options
bilinear or
ahd removes the grid, visible after the second st stretch
Thanks again and clear skies,
Steve
questions:
* should we use
develop rather than
stretch?
** does anyone have a one liner for bayer? Google gives loads of technical stuff but nothing too readable...
Good to hear!
As for your questions. Please do not stretch anything before importing your data into StarTools (and make sure autosave.tiff or autosave.fits looks the exact same as the file you're exporting from DSS).
A Bayer matrix overlays a matrix of filters (as many as there are pixels) over a mono CCD. Specifically for every 2x2 pixel "block" on on your CCD it overlays;
blue green
green red
This means that your CCD's mono resolution is re-allocated (divided up) across the 3 channels. For example if you have a 16MP CCD, you will end up with 4MP of blue information, 8 MP of green information and 4 MP of red information.
If, for example, you look at a 2x2 block of pixels, we only have one sample of blue for that 2x2 block. In other words, we're missing those 3 other samples of blue.
Debayering algorithms are nothing more than sophisticated interpolation algorithms to "make up" those missing 3 blue samples, 2 green samples and 3 red samples for each 2x2 block, so that you end up with 16MP of "data"
for each color channel. Of course, of that 16MP x 3 channels = 48MP data, 2/3rds is completely made up by the debayering algorithm; we only had 16MP (= the resolution of the underlying mono CCD) of real samples to begin with.