Masked Stretch and Image Edge Artifacts

[dmcclain]

Hi,

Sometimes, after registration and integration, my images will have a border of depleted pixels - a dark, nearly zero border along one or more edges.

I find that if I use Masked Stretch against such images, regardless of where I place my background reference region, the results have a severely squashed dynamic range. But if I crop the image border away before doing Masked Stretch, things look good.

I don't understand why that region of dark border pixels should have any effect on Masked Stretch? Those border pixels are at levels below the background region average.

- DM

[aworonow]

If you dither your subs, and you should, they they do not, of course, exactly overlay one another. O if your tracking is a bit off this could happen too, of the span of a few or so subs. Or maybe you recentered the target between sets of exposures? In any case, after registering and integrating (stacking) it is quite common to have margins that do not have the full compliment of contributions from all subs. Simply use dynamic crop to get the good stuff from the central part of the image then do the rest of your processing.

Note, it is a good idea, when aligning/registering your subs to select a reference frame than best covers the region of your greatest interest, so that the parts to be cropped away leave the sweet spot intact.

Alex W

[pfile]

my guess is that because MS considers nonzero pixels that are < than the threshold set in the UI as background, that those pixels are affecting the mean of the background...

rob

[dmcclain]

First of all, the issue is not the fact that I have edge artifacts. These artifacts have nothing to do with dithering. Rather they arise from image registration among image stacks.

And I did first think about the effect of zero pixels against the overall BG level. Surely a tiny amount of zero pixels would not affect the outcome. And those zero pixels aren't even in the selected BG region. But I'm running an experiment now, attempting to see how much of an impact they do cause.

Perhaps I misunderstand the nature of the MaskedStretch algorithm? And perhaps the BG level is extremely important to the overall effect. I could believe that much.

...

Interestingly, I found that I could zero out substantial portions (~5%) of area *inside* the BG preview rectangle and have almost no impact on the stretched outcome, as I would have expected.

And when I explicitly zero out edge pixels at the top edge, or the right edge, of the image, completely outside of any selected BG region, that also showed very little impact. Was I just imagining this?

So then I set a bunch of edge pixels to near saturation values, on the thought that among those edge artifact pixels there might be even one errant saturation level. And that had almost no effect either.

So... back to the original situation. The image here shows the original linear image in the upper left. It has a thin strip of zero pixels along the very top edge of the image. The image to the right shows the result of MaskedStretch, using the entire image as BG reference region. As you can see the dynamic range shows a pretty squashed range in the stretched outcome. (I guess dynamic range is bigger?)

The lower image shows the very same MaskedStretch being applied on the image after I cropped 5 pixels all the way around. While still squashed (as often happens with MS) there is considerably more low level information in the result.

[dmcclain]

I checked, in detail, that zero band at the top of the image. It isn't really zero, except in the R channel. (Hint?!) The values are consistently down at R = 0, G = 0.013, B = 0.012. Perhaps there is a peculiarity in the algorithm whenever there is a solid zero in only one color channel?

-------

I also went to the ultimate documentation -- the GitHub repository, and found the source code for MS. There is a parameter, called "clip" that I guessed might be related to that "Clipping Fraction" shown in the control dialog panel. Mine has never been touched, and resides at 0.00005 (pretty small). I tried setting it to zero, and got the same kind of results. But then, I noticed that the algorithm is re-scaling the image to exclude anything beneath that level, and renormalizing by the range (1 - clip).

So, I took a look at the image statistics and estimated Median - 3*MAD and put that into the Clipping Fraction box - and lo and behold - the image stretched pretty nicely. Better than ever before.

So it appears that Clipping Fraction is an important control.

- DM

[msmythers]

Just wondering, why 3*MAD?


Mike

[dmcclain]

The MAD is a robust stand-in for standard deviation, and is less affected by outlier data than a variance calculation. The actual scaling for a Gaussian distribution would be something like 1.48 MAD = 1 sigma. So perhaps I should have used 4 or 5 MAD. But that assumes we have a Gaussian distribution too.

But this was just a Q&D test and I winged it...

[Juan Conejero]

So it appears that Clipping Fraction is an important control.

It is absolutely essential. Instead of MAD you may prefer a more efficient robust estimator of scale, such as Sn, Qn, or the square root of biweight midvariance. These are also available on the Statistics tool.

But that assumes we have a Gaussian distribution too

You can safely assume it. Since we are sampling a very large (even huge) amount of pixels, and the algorithm basically works with means, the central limit theorem applies.