Synthetic Luminance....one more time....what about rejection?

[Dimitris Platis]

Basically, by reading all (I think) of the posts on this matter I have concluded that the best ways to get something a SynthL is
1)by either stacking all LRGB fits together with noise evaluation and no rejection....in which case the first question would be....what about the useful rejection parameter that keeps stray satellites and pixels away?
2) or by stacking all Luminance fits along with the SynthL (from average integration-noise evaluated) via the integration module. In this case do I activate rejection (in which case how do I enter drizzle data into the integration module since SynthL doesnt have a drizzle file since it is a product)? or not (in which case the entire Lum channel will be without any rejection at all)? Should I perform a second star alignment of the SynthL with the Luminance fits in order to obtain drizzle data?

To elaborate....I have registered all raw fits/subs (L, R, G, B) to a single Luminance fit/sub so as to avoid multiple alignment that might introduce noise.

Any ideas on how to handle this?

[RickS]

Hi Dimitris,

You integrate all your L frames to produce a L master, all your R frames to produce a R master, etc. as usual with rejection.  Then you integrate these masters (which should be free of satellite trails, etc.) noise weighted and without rejection to produce the "super" luminance.

Cheers,
Rick.

[jkmorse]

Dimitris,

I am not sure I understand since if you shot separate lum frames, then I assume you have binned your RGBs.  If you have binned the RGBs then you would actually be downgrading your Lum by adding a synlum made from your RGBs.  The theory behind the synlums is that you no longer shoot lums, just unbinned RGBs, then use those unbinned RGBs to build your synlums.

Also, if you are shooting lums and unbinned RGBs you are wasting time and not helping your image.  See this following discussion, particularly Juan's explanations:

http://pixinsight.com/forum/index.php?topic=6042.msg41037#msg41037

The second thread referenced in the first post is particularly important as it really lays out Juan's explanation.  For convenience here it is again: http://pixinsight.com/forum/index.php?topic=1636.msg9297#msg9297

Best,

Jim

[Dimitris Platis]

Dimitris,

I am not sure I understand since if you shot separate lum frames, then I assume you have binned your RGBs.  If you have binned the RGBs then you would actually be downgrading your Lum by adding a synlum made from your RGBs.  The theory behind the synlums is that you no longer shoot lums, just unbinned RGBs, then use those unbinned RGBs to build your synlums.

Also, if you are shooting lums and unbinned RGBs you are wasting time and not helping your image.  See this following discussion, particularly Juan's explanations:

Hi Jim,
I have read all these posts. It just happened that I had shot one target with unbinned Lum and RGB. So I am producing a synthLum without degradation of the image quality. Now as far as saving time is concerned....theory is one thing...but practice is another.
If I shoot RGBs only then the imaging time required is quite long (3X)...indeed far longer than when shooting LRGB (binned or unbinned). I was thinking that I could help gather more data on the L channel and still add the unbinned RGBs into the Lum.

[Dimitris Platis]

Hi Dimitris,

You integrate all your L frames to produce a L master, all your R frames to produce a R master, etc. as usual with rejection.  Then you integrate these masters (which should be free of satellite trails, etc.) noise weighted and without rejection to produce the "super" luminance.

Cheers,
Rick.

Indeed, that is a good way to do it...or perhaps....produce Lum and RGB_L (luminance of normal RGB combined with rejection) and then add them with PixelMath

[RickS]

or perhaps....produce Lum and RGB_L (luminance of normal RGB combined with rejection) and then add them with PixelMath

ImageIntegration is a more powerful way of combining Lum with synthetic Lum because it will normalize the data and calculate a noise weighted average.  If your synthetic Lum has better SNR than your conventional Lum then it will be more heavily weighted and vice versa.  A simple addition will only work well if both images have similar SNR (and compatible value ranges - you could use LinearFit to guarantee this.)

Cheers,
Rick.

[Dimitris Platis]

Indeed it is true Rick....that is why I am doing both and measuring the final SNR.

[Dimitris Platis]

Does anyone understand why we are using Average for ImageIntegration when we are creating synthL from RGB?

[RickS]

Does anyone understand why we are using Average for ImageIntegration when we are creating synthL from RGB?

What else would you use?  Average is effectively the same as summing the input images (with normalization and noise weighting.)  You can ignore the division done by Average since it's just a linear scaling of the data.

Cheers,
Rick.

[Dimitris Platis]

Would u mind elaborating on the division part of Average? What exactly do u mean by linear scaling of data?

[jerryyyyy]

Maybe I am way off base, but I am calibrating and registering in BatchPreProcessing, then I take the calibrated images with the drizzle data and put them into ImageIntegration and use the linear rejection at 7 and 5 and seems to come out way better that what I started with.  They all conveniently show up in the "Registered" folder.  I just did one with M45 where I combined the L with the B to get a synthetic L that was better than either.... IMHO. 



Maybe others could also post images at Astrobin with the exact PI parameters used. 

You know, thinking about this, we could set up a "person" at Astrobin that uploads demo images for comparison....

[RickS]

Would u mind elaborating on the division part of Average? What exactly do u mean by linear scaling of data?

The operation at the core of ImageIntegration using Average with say, R, G and B masters is to calculate (r+g+b)/3 for each pixel where r, g and b are the values of the corresponding pixel in the R, G and B masters.  So, it is summing the pixels and dividing by the number of images.

By linear scaling, I mean that there's a simple multiplication going on (multiply by 1/3 in this case.)  When you're working with linear data you can ignore this scaling.  A sum (r+g+b) or an average (r+g+b)/3 will look the same when stretched.

Note: for the sake of simplicity I'm ignoring normalization, noise weighting, rejection, arithmetic overflow, etc.

Cheers,
Rick.

[RickS]

Maybe others could also post images at Astrobin with the exact PI parameters used. 

Hi Jerry,

I find that the rejection parameters are different for every image (and every filter) to get optimal results.  Best practice is to do an integration with no rejection to find the maximum SNR and then tweak the rejection algorithm and parameters to get as close as possible without including undesired artifacts like hot or cold pixels, satellite trails, etc.  It takes a little while but that small investment will maximize the value of your precious image capture time.

Cheers,
Rick.

[jkmorse]

Rick,

Nice technique to maximize image quality.

Best,

Jim

[jerryyyyy]

Maybe others could also post images at Astrobin with the exact PI parameters used. 

Hi Jerry,

I find that the rejection parameters are different for every image (and every filter) to get optimal results.  Best practice is to do an integration with no rejection to find the maximum SNR and then tweak the rejection algorithm and parameters to get as close as possible without including undesired artifacts like hot or cold pixels, satellite trails, etc.  It takes a little while but that small investment will maximize the value of your precious image capture time.

Cheers,
Rick.

Very interesting.  I have to think this through.  I am collecting data on a couple Milky Way nebula in Ha, O and S and just integrated some 30 images each and the noise is way different just to the eye... using the same parameters.  This would be an interesting test.  The Ha was way less noisy that the other two and I was saying to myself, how am I going to get the backgrounds to look the same... was thinking what noise reduction and masks to use.  Maybe would be smarter to get the integration better then there would be less noisy images...