11.01
#...
·
·
1
like
|
|---|
|
I tried Local Normalization on my few (29x90secs) RGB subs that I captured during an almost full moon with whispy clouds today. I must admit, it worked quite well in terms of removing gradients from the moon and clouds. Do any of you use it and when? Here's the result for an approx 50 minute integration on M106 on a cloudy night (noisy as hell, but 50 mins integration is almost nothing):  M106 - 50 minutes exposure |
|
7.42
#...
·
·
2
likes
|
|---|
| I use it all the times. Most effective. |
2.41
#...
·
|
|---|
| I used to use the stand alone process for Normalization and was always pleased with it, but disliked that I couldn't Drizzle with it. Updates for PI come so frequently with major updates and I'm not sure if you caught that the latest WBPP scripts now includes normalization without the same drawbacks. Of course you can still use the standalone normalization workflow, but I'm curious if a comparison is made between the 'default' newly included script normaliztion vs. the older flow. |
6.49
#...
·
|
|---|
|
I use it when I have very unevenly lit images (variance intra-image, strong gradients, due to stray light, moon, whatever) and high variance from one image to another. Therefore it is better to normalize locally instead on doing it in based on whole images (average values), in order to avoid wrong pixel rejection during stacking. Most of the time I don’t use it, because I tend to stack the production of one single night with long focal length. It can be useful with short focal length when you have strong gradient due a wide field of view and lights from the city, for example, that are rotating during the night (and an alternative to that is to remove gradient in each image, in batch, before stacking). |
|
11.01
#...
·
·
1
like
|
|---|
I used to use the stand alone process for Normalization and was always pleased with it, but disliked that I couldn't Drizzle with it. Updates for PI come so frequently with major updates and I'm not sure if you caught that the latest WBPP scripts now includes normalization without the same drawbacks. Of course you can still use the standalone normalization workflow, but I'm curious if a comparison is made between the 'default' newly included script normaliztion vs. the older flow. The new version of WBPP is what prompted me to use it for the first time today. I think I will use it whenever I have ended up having to capture during a full moon/cloudy skies/heavily light polluted etc.. |
|
2.41
#...
·
·
1
like
|
|---|
Andy Wray:I used to use the stand alone process for Normalization and was always pleased with it, but disliked that I couldn't Drizzle with it. Updates for PI come so frequently with major updates and I'm not sure if you caught that the latest WBPP scripts now includes normalization without the same drawbacks. Of course you can still use the standalone normalization workflow, but I'm curious if a comparison is made between the 'default' newly included script normaliztion vs. the older flow. I haven't seen any negatives so far, but I haven't performed an exhaustive scientific comparison. I've been pleased with how it handled nights where the moon was strongly affecting a specific direction and later set that same night and became a non-factor. I still need to use ABE/DBE of course, but maybe my imagination but it seemed... easier to correct the gradient??? |
2.11
#...
·
·
1
like
|
|---|
|
As of one or two versions ago, it was dramatically improved, and made reliable enough to be part of most regular workflows without mucking things up. Before it was especially challenging to use on images with bright objects like a star, and even when configured “properly,” it would introduce glow/structure which fell rather far outside structure which existed in days. I think it has become an excellent tool to extend some simplification to light gradients and improve outlier rejection in stacking. It has also been very effectively incorporated into WBPP. I used the normalize scale gradients script before and it has been fantastic and routinely reliable for quite some time now. After some testing, I think normalize scale gradients is still superior, and I tend to use it instead, but I’m happy to regularly use one or the other in my workflows. I haven’t tested local normalization for this, but I’ve found normalize scale gradients can be used to model out the light gradient from images captured at my Bortle 4/5 spot using an exposure from my Bortle 3 spot. Which is also rather nifty. |
7.61
#...
·
|
|---|
|
I used LN as a regular part of the workflow at first, but really because it was included in a tutorial I started with. I then saw some comments form the developer of Pixinsight and other notable AP'ers emphatically arguing against its regular use and/or without a thorough understanding of how it works and how to use it, so I stopped. More recent forum comments and some widely varying data caused me to try it again on my current effort (M 65/66). It seemed to work pretty well on all the channels except luminance where I couldn’t find a setting that didn’t either leave rings around the stars (scale set too low) or a dark crescent along the one edge of the galaxies (scale set too high). As I wasn't sure about mixing channels with and without LN, and where it worked was only a marginal improvement, I decided to skip it. Any insight, though, as to what settings might have worked better for the luminance channel would be greatly appreciated. Mostly I just played with the scale setting. At 128, the stars had rings and at 256 (or more), the galaxies had dark edges and I couldn't find a setting between that didn't result in one or the other. Cheers, Scott |
|
7.42
#...
·
·
1
like
|
|---|
Scott Badger: In many years of using PI I never witnessed any of the issues mentioned above (default settings, scale=128) in either OSC colour or LRGB/SHO/HOO and I must have processed 1000s of frames. I have no idea what you do to get this sort of effects but I'd venture the choice of reference frame may have something to do with it. You could use Adaptive Normalization as an alternative during stacking up but it isn't as good as LN. |
|
7.61
#...
·
|
|---|
andrea tasselli: I tried a couple different reference images and also culled a bit more aggressively before using LN, but same issue. FWIW, just found a CL thread regarding the dark edge issue, but at a quick scan I don't see that it was resolved..... https://www.cloudynights.com/topic/660102-drizzleintegration-and-localnormalization-with-pi-dark-edges/ Cheers, Scott |
|
7.42
#...
·
|
|---|
| That thread seems relative of the effect of LN when added to DrizzleIntegration. I only use DI at 1x (CFA drizzle) so I might never have experienced the issue, which could be related to interpolation issues of the normalization frame. Apparently PI 1.8.9, which have yet to install, has a revamped NI process so maybe that would sort things out. |
|
7.61
#...
·
|
|---|
|
Yeah, it didn't help with my issue, but the images posted showed the same type of effect I ran into after doing LN and before any drizzle. Cheers, Scott |
