5.63
#...
·
 |
|---|
|
Hi, this might be a beginners question for some, but I just changed from a OSC to a mono-CMOS camera and I am wondering how to effectifely remove a light pollution gradient in a greyscal image (e.g. luminance channel). Doing this with OSC data is easy - any light pollution gradients are quite obvious because of their colour. But in a greyscale image, I wonder how you as a user and the software algorithm identify what's nebulosity and what is light pollution. At first, it also depends how you stack your data: My approach would be to stack and gradient-remove RGB and luminance data as 2 separate data sets. I do use APP, so I would stack the three colour channels into a final (combined) RGB stack and using the remove light pollution tool as usual. I would then stack my luminance data separately and perform a light pollution removal on this stack as well. I believe there would be the possibility to combine L and RGB data in a single APP stacking session, but I would prever to process L and RGB separately and combine them in a later step, having full control of the colour-luminance match. How are you accomplishing this with mono data? As far as I know, APP has no feature to save the "sky background box"-distribution for use on further data. So I would start with gradient-removal in the RGB-data, make a screenshot of my "final solution"-box distribution and try to rebuild that on the L-data in a second step. Is this the way to go, or am I thinking too complicated? Thanks very much for your help! Chris |
8.42
#...
·
|
|---|
| Usually, I find it's pretty clear where the background is and where it's not, but on occasion where it's not so clear I use a reference image from DSS to set points for DBE. |
|
5.63
#...
·
|
|---|
|
Yes, most of the time it's obvious and a reference image can also help. So I am not referring to galaxy images, for example, but to those photos that are even hard in OSC to process with the gradient removal tool (frame showing mostly nebulae or field of view close to the milky way center. I am wondering, if other astrophotoghraphers process their RGB and luminance data separately (that's the old fashioned way), or if they render a combined image out of their stacking software? Or do you extract a luminance layer out of the combined stack later during the processing (LAB-mode in PS offers that possibility)? I used to extract a false luminance out of the RGB data with my OSC setup, but I believe the luminance data would be compromised when doing so with an LRGB stack. Chris |
1.81
#...
·
|
|---|
| Hey Chris, more often than not now I shoot both OSC and Mono data simultaneously (because I use a dual setup). So when processing I use exactly the same points from Dynamic Background Extraction (in Pixinsight) from the OSC. Of course this might not work if not doing OSC and Mono simultaneously as gradients might not be the same. I do this by setting the points and then saving the process to the desktop. I then just apply that same process to the mono. |
1.51
#...
·
|
|---|
|
Chris, I wonder if this work around has any merit because I'd expect the gradient in the RGB stack to be close to the L stack. After stacking RGB, perform a gradient correction. Extract Lum from RGB gradient and apply it to the L stack? I have not tried that. However, the bigger problem with gradients is that they can change over time as the scope tracks the target. So if you want perfection, or close to it, you would gradient correct each image before stacking. PixInsight has a 2DPlot script that can graphically plot intensity values (horizontal, vertical, diagonal) over any part of your image. The vertical scale can be magnified. I find it very useful as a sanity check. You could also try performing a large linear stretch on the L stack so any gradient would become obvious. An image full of nebulosity is going to be very difficult, so in those cases, your eyes on a properly calibrated color monitor will be your best bet. Another option is to process everything with and without gradient removal and compare results. In the end, whatever looks best to your eyes is the right choice. The fun thing about astrophotography (pretty pictures) is making your own subjective decision on what looks right, especially in difficult situations. Rod |
 #...
·
·
2
likes
|
|---|
|
Hi, @Christian Koll The RGB gradient isn't the same as in the L, even if you'd take the L-channel (which one actually? From HSL or Lab?) from the RGB. Usually the RGB filters are designed to omitt some wavelengths in the yellowish wavelenths (check your filter spects and you'd probably see that G and R don't overlap or touch), where the man made light-pollution happens/happened (the change to LED changes the game). Nevertheless, it can indeed be a challenge to remove the gradient if there isn't any background to hold on to. The best mitigation is to minimize it from the beginning: - shoot L when object is close to meridian. - If there's the Moon, be as far away as possible or try to capture the data on a date/time when there is no moon. - Use CLS filters as a L-replacement. They can supress some light pollution and skyglow. From a processing point of view, you can try to create a manual gradient which you subtract until it seems to be correct. But that's something I would consider a measure of last resort. @Rod Hughes I wouldn't subtract a gradient from each sub frame. You'd have to have a high quality gradient for each sub since, as you say, the gradient changes through the motion over the sky and each subtraction adds additional noise. In the end it's better to subtract the averaged sky gradient than to add noise within each sub. Contrary to intuition: it will not give you perfection. CS, Björn |
|
1.51
#...
·
|
|---|
|
Chris, PixInsight has a process called Automatic Background Extractor (ABE) that should clean up your L image gradient. Set the target image correction to Division. Not sure what the process would be called in other apps. ABE works on RGB or Mono images very nice. Rod |
