Follow me
|
May 2010
Posted: May 28th, 2010
IntroGradients are often unavoidable, and they get worst the wider your field of view is. Of course, incredibly dark skies are a great help, but we don't always have that luxury.
The strategy you choose to deal with gradients will depend on the image, how severe the gradients are, and your goals. This tutorial shows you how I deal with gradients with images that also contain very faint details in the background that I want to preserve.
Many people attack gradients somewhere in the middle of the processing of an image. While the results obtained by doing this can be ok, my experience is that it's a lot better to deal with the gradients at the very beginning.
There are many reasons why dealing with gradients in the middle of the processing is just not a good idea: stretching an image with gradients is not desirable because our histogram isn't true to the data we want to process - the histogram is including the gradient data, which means we're looking at a histogram that is not a good representation of our data, and why would we want to carry the gradient data with us as we process the image and deal with it "later"? Also, color-balancing an image with gradients can be misleading, so again, ideally we want the gradients corrected before we color-balance our image, something that is better to do when the image is still linear - which also means our gradient corrections must not break the linearity of our image, they have to be done early in the process, etc. In short, gradients have been added to our image and they're unwanted, so before processing our image we should get rid of them first, and once that's done, proceeded as "usual".
The most effective way of removing gradients (other than perhaps super-flats?) is by creating a background model defining the gradient and subtracting it from our image. We subtract it because gradients are an additive effect. By doing this, we can remove the gradients and be left with an image that is still in linear form, so we can then start processing it just like we would with any image - but without gradients!
The DataThe tutorial is based on a set of luminance I captured for my M10, M12 and galactic cirrus image.
The captured data was of Ok quality, but as you will see, it wasn't free of gradients. The master file was generated from 7 subexposures of 15 minutes each at -20C temperature, with a SBIG STL11k camera and a Takahashi FSQ106EDX telescope with the 0.7x reducer. The data was captured at DeepSky Ranch, California, between 1:45am and 3:30am on May 6th, 2010.
The Goal
The goal in this session is to remove the gradients from the luminance, but at the same time trying to preserve some very VERY dim galactic cirrus that populates that area.
1 - Preliminary workWe skip the process of calibrating and registering the 7 subframes. This means we already have a "master" luminance file. We open it in PixInsight:

As usual with most astroimages, there isn't much to see.
We want to see what's in there, so we use the "Auto" function from the ScreenTransferFunction tool (STF from now on) to perform a strong "screen stretch", that is, a strong stretch of the image as presented on the screen but without actually modifying any data in the image.

Now we can see what's really there, and the most noticeable thing (besides a "bad column" that wasn't corrected during calibration) is a gradient that presents our image rather bright on the left area, and much darker on the right. Our two globular clusters show nice and clear, which is nice.
If we pay very close attention, we also notice that there is in fact some data of the galactic cirrus in the image. We can tell the galactic cirrus from the gradient, because the gradient is a uniform and gradual effect across the image, but we can also see some structural differences. Yes, they're hard to see, but with some experience (and by looking at the actual image, not at a reduced screenshot) is quite noticeable. One thing is sure, we won't be able to do anything with that galactic cirrus unless we get rid of the gradient, and fast!
2 - Creating our background modelThe first thing I do to create an acceptable background model is to create a duplicate of the image, and apply a non-linear histogram stretch. I do this because it will then be easier to place the samples used to create a background model based on this gradient.

Our gradient is back, indeed. In this histogram stretch we can also better see some of the galactic cirrus data that we do NOT want to remove.
Now we use the DynamicBackgroundExtraction tool (DBE from now own) to construct the background model.
Although I am not going to use the DBE symmetry function, I like to set the symmetry point at a place that seems to make sense to me, all the way to the right of the image in this case.

VERY IMPORTANT: When placing the samples that later will be used to create the background model, first I will place just a few of them, at an average of perhaps just 5-8 across. The reason is twofold. First, we're trying to model a gradient, and gradients are usually very smooth and gradual. If we were to place many samples, our model will start not to be as smooth and gradual as the gradient, as I will show you in a minute. The other reason is that we want to preserve the very subtle differences in the galactic cirrus data in the background, and we definitely do not want the samples to catch these differences.
In the screenshot above you can (barely) see the sample points in cyan blue. Later you'll be able to see them much better, so I'll talk about that then.
The next step is to SAVE this process as a "Process Icon". The reason is, we do not want to apply the DBE to this non-linear image. We have stretched this image to get a better feel of where the samples should go. By saving the process, we can then apply it to our real "good" image later.

Notice in the screenshot above the little icon next to the mouse cursor. We've created this process icon by dragging the "blue triangle" at the bottom-left of the DBE dialog over the workspace.
3 - Applying the background model
We can now close the DBE dialog and the stretched image. After doing that, we double-click on the process icon, and we "magically" apply to our "good" image the parameters we just defined earlier:

Here is when I can better show you where I've placed my samples. Notice I first auto-generated about 6 samples per row (equal spacing vertically) and then I've placed a few samples manually on the left area, where I noticed there was a very "short" darkening gradient, that our model background wouldn't pick unless we also set a few more samples there. Generally, in order to protect the very faint background structures, we should do an even more careful placement of the samples across the image, but as we shall see, even a more general sample placement can yield good results.
With that done, we're ready to apply the DBE. Notice (if you can read it!) that I have selected "Subtraction" as the correction formula. As I mentioned earlier, gradients are of additive nature, so in order to correct them, we must subtract the background model, rather than dividing it (which is what we'd do if we were dealing with vignetting, for example).
And here's our corrected image after subtracting the background model created by the DBE process:

Not much to see, right? Let's now apply a STF to both, our corrected image and the background model. This allows us to see whether the gradient has been successfully corrected as well as the shape of the background model we've used:

On the left you see the background model. Notice it's a smooth and gradual model, which is exactly what we wanted. If we were looking for complete perfection, we do notice that there's a few areas in the model that don't seem to be "just gradient corrections". In that case we would go back to the DBE tool, readjust the position of our samples, perhaps also readjusting some of the modeling parameters, using as a guide the background model we just created - which "tells" us where it didn't do a good job.
On the right you see the corrected image (with a very strong STF stretch). We do notice the background is not perfectly flat. Did we fail? Nope, that's the signal from the galactic cirrus! Other than that, we can tell the gradient is pretty much gone.
We disable the STF and our image is ready to be processed. Just as when we started but without the gradient:

4 - Verifying faint background signal
Although we are confident that the uneven background signal we saw in the STF'ed image after applying our background model is not the result of gradients, in part because we were able to see that the differences in background brightness of the "screen-stretched" image do not correspond with the subtle differences we notice in our background model, a reassuring check would be to compare a quick non-linear stretch of our image with the same area from the IRAS survey, Here's our image:

And here's the same area from the IRAS survey:

Obviously our image does not offer the same level of detail - in some cases it might, once processed, but certainly not at this point where all we're doing to our image is just a screen stretch - but we can see that the background areas that appear to be darker in our image roughly match the darker areas in the IRAS image. To get an even closer picture, we can apply some multi-scale processing techniques (MS) to our image so we can bring out even more clearly the background signal - for this purpose we have also applied some strong histogram adjustments (HS) over-highlighting bright areas and over-darkening darker background areas:

As I think it's clear, our bright background structures match pretty well with the structures from the IRAS image. Of course they do NOT match exactly, that's why when making that assesment, we must consider a couple of things:
-
We've just collected 7x15 minutes subexposures from a less than perfect sky, so the signal we've captured from the cirrus is not going to be as detailed as if we had imaged the Orion Nebula.
-
The quick multi-scale process we've applied usually blurs the large scale structures - our purpose at this point is to identify whether bright intensities in the background we have now more-or-less match the bright areas from the survey image, and blurred structures are ok to make that assesment. You can tell by looking at the final processed image that when processed carefully, the background structures don't look exactly like the "quick blur" we just did.
-
The resolution and quality of the image we've obtained from the IRAS survey is also not ideal - areas that look very dark in the image may not be really absent from galactic cirrus for example. I have seen images taken with large telescopes of parts of the sky that display a large and dense amount of galactic cirrus where the images from the IRAS survey barely show any.
And of course, what really matters for the purpose of this tutorial is that the gradients we originally had in the image have no influence in this background signal, that we have been able to remove the gradients using an appropriate workflow, and that in the process we have not destroyed faint background details.
___
NOTE ADDED ON 5/16/2011: Teri Smoot processed WISE IR data of this
area and created a video that overlaps her results with the final image
used in this tutorial. Although both sets do not match 100%, I
think the results are very interesting. You can see the animation here.
___
5 - A note about background samples
When creating a background model, some people tend to define a large number of samples with the idea that the more samples we place, the more accurate the background model will be.
The problem with this approach when removing gradients is that, if our image contains subtle variations in the background NOT caused by gradients, a background modeled after many samples will catch these variations, more so if the variations are not so subtle.
For example, look what happens in this case if we generate and apply a background model that was created from a large number of samples:

At the top-left is our original image with the sample marks (yup, that's a lot of samples!).
At the bottom-left is the background model generated. You can just tell by looking at this background model that it's not the right model to correct a gradient - unless you believe that a gradient could have that shape!
As a result, on the left is a screen stretch of the image after we've applied the background sample. Not only the background details we know this image has are pretty much gone, but also we can see some darkened areas - especially around bright stars or even the two clusters - that we can tell are processing artifacts. We've over-corrected our background.
So although there are cases where a large number of samples is justified, be careful when dealing with gradients, and always stretch your background model to make sure that it indeed shows the shape of what you'd expect from a gradient.
6 - Wrap up
As always, this tutorial takes a bit of time to read, but it really only involves four very very simple processing steps:
- We screen-stretch our image to view the gradient
- We histogram-stretch a duplicate of the image to place samples at the right places
- We create and apply the background model
- We verify that the model generated is appropriate and that our final image is properly corrected
For someone with some experience working with PixInsight, this session could be carried out in just 5 to 10 minutes.
As always, feel free to leave comments, questions, suggestions...
|
Posted: May 27th, 2010
I often get requests from using my images in cases when permission isn't really needed. Before asking, it might be helpful for you to read the following.
As stated at the bottom of all pages in DeepSkyColors.com, all the images I post here are licensed under a BY-NC-ND Creative Commons License.
The BY part means that if you use any of the images posted here, you must attribute the work in the manner specified by the author. So what are my requirements as far as work attribution? All I ask you when using any of my images, as far as crediting authorship, is to include at least this minimum required credit line:
Rogelio Bernal Andreo (DeepSkyColors.com)
Such credit line should be readable when looking at the photograph. That means you shouldn't include the credit line in such a way that a casual viewer of the image isn't able to read the credit line (for example using a font size that is very difficult to read). At the same time, it is suggested that the credit line doesn't distract the viewer from the image And just to be clear:
- The NC part means Non-Commercial, in other words, you may not use any of my images or content for commercial purposes.
- The ND part means Non-Derivative, that is, you may not alter, transform, or build upon any image or content posted on DeepSkyColors.com, regardless of whether I have posted such content somewhere else.
As long as these three conditions are met, you are free to use any image or content posted here on DeepSkyColors.com and no specific permission is required from me. Does that mean you can not use my images for commercial purposes or that you cannot create derivative works, etc? No. But for any of such uses you must contact me first.
|
Posted: May 26th, 2010
About WhiteCalWhiteCal is a simple Photoshop plug-in that allows you to select an area of an image (a sample), and then it'll do a complete RGB color balance assuming that the average color in the sample is supposed to be white/neutral. The sample can be anything you can select using any of Photoshop's selection tools: marquee/lasso tool, magic wand, color range, etc. There are several different applications for this plug-in. One is to do a standard white balance adjustment... Say you took an picture and the colors look odd. If there's an area of the image that you know it should be white (or at least of neutral color), you could select a part of that area, and then use WhiteCal to adjust the colors of the entire image (not just the selection!) so that the average resulting color of the selected area will in fact become white/neutral, and the colors of the rest of the image become adjusted according to the same coefficients applied to make the selected area white/neutral. For astrophotography aficionados, this is very useful for example to do color balance on daylight pictures taken with a modified DSLR camera. In astrophotography, WhiteCal can also be very useful to do a color balance based on a G2V star: simply select the star (you can use the lasso/magic wand tool for that) and run WhiteCal. Do try to avoid selecting saturated pixels. Some people also like to do the color balance of an image of a galaxy by assuming that the core of the galaxy - or all visible light coming out of the galaxy - is white. Again, simply select the areas you assume their average should be white, run WhiteCal, and the colors of the entire image will be balanced accordingly.
RequirementsTo use WhiteCal you need a computer running Windows (tested on XP, Vista and Windows 7) and Photoshop (tested on CS2, CS3, CS4 and CS5). WhiteCal will likely work under previous versions of Windows and Photoshop but I haven't tested it. If you successfully runWhiteCal in any of the not-tested versions of Windows and/or Photoshop, let me know.
Why not Mac? ... Short answer: because I don't have one, therefore I cannot compile and test the plug-in for the Mac.
Download itDownloading WhiteCal is easy, simply click one the links below:
For any version of Photoshop (except CS4 64 bits): DOWNLOAD WhiteCal
For Photoshop 64 bits ONLY: DOWNLOAD WhiteCal 64bits
By the way, WhiteCal is free (as in "free beer") and I want it to stay that way, so permission is NOT given to include this plug-in in any commercial package. If you downloaded WhiteCal, whether standalone or as a part of a package, and paid for it, please let me know. Having said that, if you find it useful and would like to make a small donation, please use the "Donate" button below. This will entitle you to receive notifications of new upgrades to this plug-in. The Donate button will take you toPayPal - don't worry when you see the donation goes to AR Networks. Yes, that's me.
Installing WhiteCalOnce downloaded, you'll need to unzip the WhiteCal.zip. This will extract the WhiteCal.8bf file.
Once extracted, copy the WhiteCal.8bf file to the Plug-Ins directory in your Photoshop installation.This usually is something like C:\Program Files\Adobe\Adobe Photoshop CS2\Plug-Ins
After you've copied the file to the Plug-Ins directory, start (or restart) Photoshop.
Using WhiteCalWhen you're ready to use WhiteCal (you'll need at least one image loaded in Photoshop), first, with the lasso/marquee/magic wand/color range/etc tool select the area you assume to be white/neutral. Once that's done, go to the Filters menu, find the DeepSkyColors menu option, select it, then click on the WhiteCal sub-menu option. If you don't see it there, chances are you did something wrong when you copied the WhiteCal.8bf file, so double-check you indeed copied it to the right directory. Again, don't forget to restart Photoshop anytime you copy a plug-in filter to the Plug-Ins directory so Photoshop knows it's there. After running WhiteCal, the plug-in will compute the coefficients for the selected area, and present them to you in a window that looks like this:

At that point, you can simply click OK to accept the values WhiteCal has calculated, or if you like, you can enter your own.
What happens if I don't make a selection before running WhiteCal?WhiteCal will simply assume the area selected is the whole image.
Does WhiteCal work well with saturated areas?Let's just say that WhiteCal will not complain but the results will not be good. The reason is because right now WhiteCal does not ignore saturated pixels, so they too are taken into account when calculating the offsets. This however will influence the offset values given by WhiteCal. One of the things in my to-do list is for WhiteCal to detect saturated pixels in the selected area and ignore them when calculating the offset values, and at the same time, being able to determine if the amount of non-saturated pi is large enough to compute acceptable offset values, and complain otherwise. In the meantime, when you do your selection, please make sure that either the sample (the selected area) has no saturated pixels, or that at least there's a substantial larger amount of non-saturated pixels in it.
A note about lightnessWhiteCal may affect the lightness of the image, especially in cases where the "correction" is big. This is because the current version of WhiteCal does not save the lightness prior to applying the offset values to the RGB channels. Since the lightness in an RGB image can be extracted from the RGB values (it involves a conversion to CIELab color but we won't get into that now), any changes to any RGB channel - which is what WhiteCal does - will affect the lightness.
In order to preserve the exact lightness as the original image, it is recommended to follow this process:
- Duplicate the layer where you'd like to apply WhiteCal.
- Make the blending mode of that new copy to "Color".
- Apply WhiteCal over that new layer.
- Merge that new layer back with the original
The above process will adjust for color balance without affecting the lightness at all. Again, for small corrections, you could use WhiteCal directly over your working layer, although in general I do recommend following the method I just described.
Bit depthWhiteCal should work on images of either 8, 16 or 32 bit depth. If you find that WhiteCal didn't work with your image, again, let me know. Regardless of the bit depth of the image, all calculations done by WhiteCal are done internally in 32 bit floating point mode.
Color ModeWhiteCal only works well when the image is in RGB mode. You can still use WhiteCal when you're in Lab or CMYK modes for example - WhiteCal won't complain - but the results will not be what you were expecting. Although this is something WhiteCal should take care of internally - say converting the image to RGB mode internally, and when it's done convert it back to whichever mode it was before - at this point WhiteCal does not check the current color mode being used, and it simply assumes the image is in RGB mode, so you must make sure your image is in RGB mode prior to using WhiteCal. Also, make sure you didn't go to the Channels palette and select just one channel, or WhiteCal will complain with a " problem with the filter module interface". WhiteCal needs all three channels active in order to work.
WhiteCal and masksBecause WhiteCal uses a selected area to determine the RGB offsets - and then it applies these offsets to the entire image - you cannot apply WhiteCal to just one area of the image: the selection is being used to define our sample! Now, if you really need to apply WhiteCal to just one area of the image, you can still do it by creating a duplicate layer, applying WhiteCal to that layer, and then using a mask over that layer to hide/reveal whichever areas you need.
|
Posted: May 25th, 2010
About RGBCRGBC is a simple Photoshop plug-in that allows you to easily and very precisely modify the weights of the red, green and blue channels in an RGB image.
RequirementsTo use RGBC you need a computer running Windows (tested on XP, Vista and Windows 7) and Photoshop (tested on CS2, CS3, CS4 and CS5). RGBC will likely work under previous versions of Windows and Photoshop but I haven't tested it. If you successfully run RGBC in any of the not-tested versions of Windows and/or Photoshop, let me know.
Why not Mac? ... Short answer: because I don't have one, therefore I cannot compile and test the plug-in for the Mac.
Download itDownloading RGBC is easy, simply click one the links below:
For any version of Photoshop (except CS4 64 bits): DOWNLOAD RGBC
For Photoshop 64 bits ONLY: DOWNLOAD RGBC 64bits
By the way, RGBC is free (as in "free beer") and I want it to stay that way, so permission is NOT given to include this plug-in in any commercial package. If you downloaded RGBC, whether standalone or as a part of a package, and paid for it, please let me know. Having said that, if you find it useful and would like to make a small donation, please use the "Donate" button below. This will entitle you to receive notifications of new upgrades to this plug-in. The Donate button will take you toPayPal - don't worry when you see the donation goes to AR Networks. Yes, that's me.
Installing RGBCOnce downloaded, you'll need to unzip the RGBC.zip. This will extract the RGBC.8bf file.
Once extracted, copy the RGBC.8bf file to the Plug-Ins directory in your Photoshop installation.This usually is something like C:\Program Files\Adobe\Adobe Photoshop CS2\Plug-Ins but it may be different depending on the operating system and the Photoshop version you're running.
After you've copied the file to the Plug-Ins directory, start (or restart) Photoshop.
Using RGBCWhen you're ready to use RGBC (you'll need at least one image loaded in Photoshop), g the Filters menu, find the DeepSkyColors menu option, select it, then click on the RGBC sub-menu option. If you don't see it there, chances are you did something wrong when you copied the RGBC.8bf file, so double-check you indeed copied it to the right directory. Again, don't forget to restart Photoshop anytime you copy a plug-in filter to the Plug-Ins directory so Photoshop knows it's there.

From there, just enter the values you want in the R, G and B boxes, and click OK.
Does RGBC rescale my input?Yes. Scaling in this context means that, just like if you enter the values 1:1:1, RGBC will do nothing to the image, likewise it won't do anything if you entered the values say 2:2:2. It also means that if for example you entered the values 1:2:1, RGBC will leave intact the green channel (the channel to which we assigned the value 2) and reduce by half the values for the red and blue channels, rather than leaving untouched the red and blue channels and multiply by 2 the green channel. This is done for two reasons: first, so that RGBC works regardless of thale used to calculate the offsets, and second to prevent saturation.
A note about lightnessRGBC may affect the lightness of the image, especially in cases where the "correction" is big. This is because the current version of RGBC does not operate in the CIE*Lab (or CIE*XYZ) modes that separate luminance/lightness from color data, but directly on RGB mode. Since the luminance/lightness in an RGB image is the result of combining the RGB values, any changes to any RGB channel - which is what RGBC does - will affect its luminance or lightness.
In order to preserve the exact lightness as the original image, it is recommended to follow this process:
- Duplicate the layer where you'd like to apply RGBC.
- Make the blending mode of that new copy to "Color".
- Apply RGBC over that new layer.
- Merge that new layer back with the original
The above process will adjust for color balance without affecting the lightness at all. Again, for small corrections, you could use RGBC directly over your working layer, although in general I do recommend following the method I just described.
Bit depthRGBC should work on images of either 8, 16 or 32 bit depth. If you find that RGBC didn't work with your image, again, let me know. Regardless of the bit depth of the image, all calculations done by RGBC are done internally in 32 bit floating point mode.
Color ModeRGBC only works well when the image is in RGB mode. You can still use RGBC when you're in Lab or CMYK modes for example - RGBC won't complain - but the results will not be what you were expecting. Although this is something RGBC should take care of internally - say converting the image to RGB mode internally, then back to whichever mode it was before - at this point RGBC does not check the current color mode being used, and it simply assumes the image is in RGB mode, so you must make sure your image is in RGB mode prior to using RGBC.
RGBC and masksIf you preselect an area in your image - either with the lasso tool, select range, etc. - and then run RGBC, you may be in for a disappointment when you notice that RGBC completely ignored your mask and applied the effect to the entire image. Although I guess a case could be made where one would like to modify the RGB coefficients of just one area of an image, at this point the purpose of RGBC is to modify the offsets of the RGB channels for the entire image. If you really need to apply RGBC to just one area of the image, you can still do it by creating a duplicate layer, applying RGBC, and applying a mask to that layer.
|
Posted: May 19th, 2010
Our good friend Eric Zbinden has put together a table listing all "dark periods" (no moon, between astro twilight) for 2010. The times given in the table are for the night following noon of the shown date and are corrected for daylight saving time in the summer months. Hope you will find it useful
A few tips in how to read the table:
- This Table Summarizes the period of darkness between astronomical twilights with the moon below the horizon.
- Time notation follows military time without trailing zeroes (4=4minutes past midnight, 130=1:30AM, 1458=2:58PM, etc)
- All time shown for a given date are happening during the night immediately following noon time on that date (i.e. if you were to go observing/imaging after work on May 4, the moonless period of the night would start at 9:43PM on May 4 and end at 1:43AM on may 5.
- Blank cells mean the moon is above the horizon between the astronomical twilights.
- Original moon rise/set and astronomical twilight times from the USNO website.
Underscored cells denote daylight saving time start and finish
|
Posted: May 15th, 2010

The area of Rho Ophiuchus, Blue Horsehead and Sharpless 1 - The head (and "shoulders") of the scorpion constellation - is without a doubt "the mother of all pretty pictures", and in this 3x4 mosaic I tried to show them all of them in a family portrait.
The image is a 3x4 mosaic with the FSQ+reducer+STL11k captured over 4 nights (plus 800 more miles in my SUV!!).
The interesting thing is that each frame is only 3x5 minutes of luminance, bin 2x2 (see details after this writeup). I am very very surprised to get this quality with so little data. I know binning reduces read noise but I wasn't expecting this...
I would have not done 3x5' and bin 2x2 if it wasn't because when I planned this FOV I didn't calculate it right so I thought I needed a 2x3 mosaic. It was when I was at DARC and ready to start when I realized I screwed up, and after 5 minutes of "what the heck I'm going to do now" I decided to still go for the entire luminance in one night, and do 3x5' 2x2 per frame instead of 3x10' 1x1 as I had originally planned. Either way I think that the short exposure times played on my favor, keeping the stars under control in an area that has more stars than background!!
Eric Zbinden was right next to me that night. He can confirm the madness I was in for the whole night: since I don't use automation software (CCDCommander, etc) I had to switch to a new frame every 15 minutes, and since I also don't do platesolves, I had to make sure each new FOV would match the right area (manually slewing with TheSky6's mosaic tool cannot be trusted 100%). Good thing I didn't need to rotate the camera between frames for this composition!
Even with that, the last two frames were bad, as the sky was already clearing that night, so on Tuesday 18th, I headed out again, and after taking those two frames, since I had time that night to keep going, I started with the color, and after seeing the results with the lum, I went for marginal data as well.
But I knew Tuesday wouldn't be enough, and it wasn't, so I went out again on Wednesday (there's some bright stuff called Moon which is setting rather late these days but still giving 3+ hours of darkness). But late on Wed I was getting tired, and rather than risking falling asleep at the wheel on the way back home, I packed and went home short two RGB frames.
So I went out on Thursday, again. I headed to Montebello (tired of driving so much) but when I got there it was all foggy, so I drove all the way near to Dinosaur Point, which was SO WINDY I had to retreat and I setup not far from the Hwy 152 entrance to Henry Coe but away enough from the road so the cars lights wouldn't be a bother, and there I captured the last two color frames, and went home.
Full disclosure: the areas around Antares and the blue horsehead use color from the two images of those areas I took last year. Likewise, the blue horsehead has luminance from that image as well. It looks better despite I actually lost some resolution. Also, at some point in the processing I "killed" the color in small all stars, so they're all white except the big ones (and the color in the big ones is blown out), so I may go back to this image and be careful with that!
Frame adaptation was very challenging, and the reason I decided to use Photoshop instead of PixInsight for that, as it gave me more freedom to do it, by using layers and manually defined masks, as even after applying background models to each frame to correct gradients, although signal strength was similar, no two frames shared an even background illumination across the overlapping areas, so I would stretch each frame looking for a visual match, and re-stretch using painted masks to correct seam differences. Although I usually try to stay away from painted masks (it's not a religious thing, I simply have more fun using luminance-based masks) in mosaics like this one with somewhat marginal data, I just can't get away with using more strict frame adaptation techniques.
So that's the story. 800 miles and a very unhealthy "schedule" for a pretty picture. I'm seriously considering switching to another hobby, like reading on bed or something :-)
[ Hide image details]
|
DATE May 15~21th, 2010 (4 nights)
PHOTO 3x4 Mosaic. Exposure: L: 3 x 5', RGB: 3x3' each, for each frame Total: 42 minutes per frame, 8.4 hours total Focal: 385mm, f/3.6 |
EQUIPMENT Imaging Scope: FSQ 106 EDX w/Reducer Camera: STL11k Guide Camera: StarShoot Autoguider Mount: EM-400
|
SITE & CONDITIONS DARC Observatory Seeing: Average Transparency: Good
SOFTWARE Stacking: DeepSkyStaker Processing: PixInsight & Photoshop
|
|
Posted: May 12th, 2010

This image covers an area mainly populated by IFN that Steve Mandel named "The Angel Nebula".
The framing is not exactly the one I was looking for - I wanted to have more data on the top area, but I had to crop the FOV as I didn't perfectly frame the red subs (each set was done on different nights, and the lum collected over two nights) since I'm still not doing platesolves and just eyeball the framing. The LGB data does show more data from the top (maybe I should re-take the reds!).
The image is not silk-smooth because keep in mind this is very faint nebulosity and although it may look easy to make it pop, it's still a bit of a challenge. I could reduce the noise a bit more, and some people may feel saturation is a bit too high, but this is how I like it. What I think it's becoming more clear to me is that, despite my color data is not to a point I would consider optimal, and my color balancing is not scientific (I don't use a g2v star or similar techniques), the color of the IFN tends to go more to the brown than to the blue.
So far, the only other image I know from this area is in fact the image from Steve Mandel:

In the image below you can see where this FOV goes, taking as a base the mosaic I did last month (the angel in this case is upside down):

Processing involved mainly DBE, 3-4 unmasked histogram adjustments, one ACDNR pass, one MorphTransform, and of course, color balance, LRGB combine and gradual saturation. The processing did not involve any masked histogram adjustments, curves (except for saturation), DDP, HDR or similar techniques - to better honor relative differences in brightness than DDP, HDR or similar techniques would, for example.
[ Hide image details]
|
DATE May 12th, 2010
PHOTO Exposure: L: 20 x 15', RGB: 5x15' each, Total: 8.8 hours Focal: 385mm, f/3.6 |
EQUIPMENT Imaging Scope: FSQ 106 EDX w/Reducer Camera: STL11k Guide Camera: StarShoot Autoguider Mount: EM-400
|
SITE & CONDITIONS DeepSkyRanch, Dinosaur Point, Lake San Antonio, Little Panoche Reservoir, California (4 nights) Seeing: From poor to very good, depending on the night Transparency: From average to excellent, depending on the night Miles Driven: 850 +/-
SOFTWARE Stacking: DeepSkyStacker Processing: PixInsight 1.6
|
|
Posted: May 8th, 2010
Here's a quick view of most of the ClearSkyClocks around the SF Bay Area (plus a couple not so much "around")... If you would like me to add some more, let me know.
|
Posted: May 7th, 2010
IntroThe purpose of this tutorial is to show how, using multi-scale techniques,we can bring in our image very very faint details that usually would go unseen,even in cases where we have successfully extracted very faint stuff already, of course without degrading anything else in our image.
The tutorial uses an already processed version of my IFN Wide Field 2x5 mosaic.
If you would like to see the screen-shots at a bigger resolution, simply click on the corresponding "tiny" screen-shot. A few screens-hots are actually shown in the page at the maximum resolution in which they were captured, though.
The Data
The captured data was of good quality, but not a lot of it. The master files were generated from 6 subexposures of 15 minutes each,and 3x3 minutes for each RGB channel, with a SBIG STL11k camera and a Takahashi FSQ106EDX telescope with the 0.7x reducer. The data was captured at Lake San Antonio, California over four nights - LSA is a dark site that sits right at a "gray" border in the Bortle scale, surrounded by blue and some green/yellow areas. For a light pollution map of Lake San Antonio, click here and look for its location on the bottom-right corner of the image.
The Goal
The goal in this session is trying to reveal very very faint data in regions of our image we suspect might contain such extremely faint data, as long as we decide that revealing such data makes sense from both an artistic and a documentary perspective.
1 - Preliminary workThe work detailed in this tutorial was performed over an image almost completely processed:

By observing the above image, we noticed that the area above the two arches (top-right) doesn't present any significant IFN structures. We wonder if there's any... For that we could simply stretch very aggressively the image, but because the image has gone through significant processing,we would get a more solid idea of whether there are IFN structures in that area by executing the aggressive stretch over an image in its early stages of processing, preferably in linear form. So we do just that and this is what we get:

Please ignore the still-uncorrected seams and other "defects", as this is done from an image almost in its very original form.
We can immediately see that in particular, there's a visible structure coming out off near where the two arches join - displaying a "3" shaped cloud. We therefore do have very faint structures in our image that are not appearing in our processed image.
Now, there is a risk in trying to process an image for very faint stuff after the image has been through a complete or almost complete processing cycle. The data in our processed image may not be nearly as reliable. As far as work-flow goes, this is NOT the best moment to do this. We should have noticed much earlier in the process and attack this area back then, not now. So this is an after-thought and it involves risks we would need to keep in mind. As long as we are aware of it and we perform the needed verifications in the end, my opinion is that we can proceed.
2 - Breaking the image into large and small scale structures
First, let's remember what we're looking at:

That's a pretty nice image. We have noticed however, that the area above the two arches in the top-right area is rather dark, and we have verified that there are IFN structures there. Our goal then is to see if we can extract that information without perturbing the already processed data, and if we can do so in a reliable manner. The data is still in 32 float bit depth,which, despite our monitors can't display such large dynamic range, it should help us in our little quest.
We are going to follow a multi-scale approach, so our first step is to break the image into two (maybe three if we feel it's necessary) different scale structures: large scale structures, and small scale structures.
For that we use the ATrousWaveletTransform tool (ATWT) in PixInsight. We start by generating the image with the large-scale structures. This is accomplished by only selecting the residual layer ("R") in the ATWT tool, over a 4-6 layers dyadic sequence.

The above image may just look like a blurred version of the original. Well, in fact it is a "blurred" version of the original! The difference is that unlike a simple Gaussian blur,this image has been generated by decomposing it into a series of scale layers, each of which contains only structures within a given range of characteristic dimensional scales, and we have selected to retain in this image only the very large structures. A Gaussian blur attenuates high-frequency signal, so it is a low-pass filter. A wavelets operation using a Gaussian function is a series of low-pass filters, and the way we're using it, it will generate similar results but conceptually we can better decompose the image into different scales.
Let's build now the small-scale structures image. This is easily accomplished with PixInsight's PixelMath. All we do is subtract the image with large-scale structures from the original image, so what we have left from this operation is an image defining only the structures that were removed from the large-scale image, in other words, the small-scale structures. See below a screen-shot after this PixelMath operation has been performed, and notice how the image at the bottom only contains the small details from the original image. If this image looks similar to what you usually get when you apply a high-pass filter, you're of course right.

Now.. The image defining large-scale structures looks ok, but it is still defining some structures that we probably don't want to see there. For instance, there's clearly some glow from the brighter stars, and we want to minimize that. We want to see if we can reveal the faint dust, not star glow.
So we'll repeat the ATWT process once again, this time taking as the source our image with large scale structures, and create a new image with even larger scale structures.
See below the screen-shot displaying our three images:

From now on I'll refer to each image as follows: SS for the image defining the Small Scale structures (bottom-left in the screen-shot above), LS for the image defining Large Scale structures,and MS to the image defining even larger scale structures (Mega-large structures? :-)
3 - Processing large scale structures
Now that we've broken our image into three images, each of them defining different scale structures,we start doing some processing in them. We start by stretching the histogram to the ML image. Not too much, but enough to see if there is "stuff" in our targeted area.
And yes, the area that once was mainly dark, now reveals some structures - still faint, but now visible.

This is actually the epicenter of this processing session - whatever we do here is what will contribute to the enhancements we want to add to our image. We can stop right here after this stretch,or we could try many other things... We could increase the color saturation so the structures we're"revealing" also come with an increment in color visibility... We could apply some wavelets to enhance the structures we're bringing from the "darkness", we could use curves and/or PixelMath to intensify the contrast in these structures, we could even experiment with HDRWT...
And these improvements aren't limited to the MS image only. We could also add some sharpening to the SS image for example, or also experiment with any of the processes mentioned in the last paragraph. Likewise for the LS image.
This is not to say we should go crazy. We must keep our eyes on our goals and on what the data is"telling" us. My point is only that we have a plethora of tools we can use that may (or may not) help us achieve that goal, and that's part of the fun I find in image processing - that we can experiment with these tools to see which ones help us reach the goals we aim to achieve.
In this example I decided to just stay with this somewhat subtle histogram stretch, since that's all I want at this point.
Of course, after our stretch to the ML image, everything else is also stretched, and we don't want to bring all this back to our image (we could but it's not what we have decided we wanted to do during this session), so the next step is to create a luminance-based mask that will protect everything but the darkest areas in our image.
4 - Creating the luminance-based mask
To create our mask we start by extracting the luminance from the original image.

With that done, we do a slightly aggressive histogram stretch, then use the ATWT tool to reduce the image to large structures. We don't want the mask to be based on very very large structures, so in this case, excluding only the first five layers using a dyadic sequence works well. The reason we don't want to go further to say, 6, 7 or 8 layers is because, as we will see in a minute, it's not a bad idea to include in the mask some bright "spotting" caused by large stars. If we extracted only the very large scale structures, such "spots" would be gone, since they would fall under a"smaller scale" category. Also, our mask may not be protecting well our data.
Here's our mask after the histogram stretch and isolating large (but not very large) scale structures:

Now we need to adjust our mask to protect everything but the darkest areas.Luckily, this is easy to define with the binarization tool. Well, actually it's really not about luck. Since we're targeting only the areas with the darkest background, a threshold point can be found that isolates these areas from the rest.
In this case, such "darkest area" is clearly the one above the two IFN arches,but if we had other areas similarly dark in the image, it's ok. If that happens, we can decide whether to manually mask those other areas or leave them.If we leave them, all that would happen then is that we would be "bringing up to par"the fainter signal in those areas as well, which may be a very good thing depending on the case. If we choose to mask them out manually, that's also ok as long as we have a good reason, both from an artistic and a documentary point of view (more on that in a second).
After visually adjusting the threshold with the Binarization tool on our to-be mask, this is what we get:

Indeed, we have been left with the darkest regions in the image. Two things call our attention:
- We haven't found a threshold point where only the area we're targeting is excluded.
So we need to make a decision of whether we'll leave the mask as it is,meaning our stretch will affect those areas as well, or whether we choose to manually protect those areas (making them white, basically). By looking at the original image and at a heavily stretched view of our almost-unprocessed image we can see that those other "black islands" happen over areas that don't have any significant additional IFN data, so if we apply the additional stretch, it will not contribute to enhance very faint details,and instead, rather than "extracting" additional very faint data, we would remove from the image the fact that the IFN is less dense in those areas in contrast with their surroundings. This brings up a difficult question that I'll address in a second.
- There are some bright circles in our targeted area. That's ok and in fact not a bad thing as we shall see in a moment.
So what should we do with these "dark islands"? We have three options:
-
Do nothing, and abandon this session. If we do this, our image will not document the fact that above the arches there are differences in IFN density.
-
Leave the mask as it is. This will reveal the IFN above the arches, but our final image will remove or attenuate at least the also very important detail that in the "black island" areas there is an important change in IFN density.
-
Manually make sure the "black islands" also get mask protection.This will reveal the IFN above the arches, and preserve the fact that the areas now targeted by the "black islands" have a lower IFN density.
Based on the above three options, I determined that the third option is the one that better reflects "where there is IFN and where there isn't".I conclude then that manually masking those areas is the best decision in order to meet our goals, and that the documentary value of the image is greater by choosing that option. Although we have decided to manually mask all dark areas other than the area above the arches, before doing that, though, in order to smooth transitions when we use our mask, we'll apply an ACDNR (noise reduction) without any type of protection adjustments or luminance mask. The reason we do this fist is to see how an ACDNR could contribute to making these "stray" dark areas perhaps more appropriate for the case at hand without having to manually adjust the mask. After applying the ACDNR, this is what we get.

Before going any further, we notice three things:
- First, we see that the ACDNR didn't do much as far as fainting the "secondary black islands".We therefore will be using the clone stamp (there's no Paintbrush in PixInsight) to manually make these areas white.
Using the clone stamp (or a paintbrush) to "mess up with masks" is quite acceptable to some people but almost sacrilegious for others. For this second group,the message is: We are about to apply a histogram stretch with a mask. This means we have already made the decision that we want to brighten some areas in our image while not doing so in others (not only that, we're stretching only very large scale structures, so we're even more selective).And although some may think that the moment we use the clone stamp (or the paintbrush) to alter a mask we are introducing a very arbitrary processing to our image, I have tried to explain the thinking process that led to this decision. It is a 100% reproducible and non-arbitrary process that rather than ignoring what the data tells us, it contributes to a better representation of the real differences in IFN density.
We will then proceed to "whiten" these black "spots" with the clone stamp tool.
-
Second, the tiniest stars that were still"seen" in the large dark area of our mask are pretty much gone after applying the noise reduction. That is good.
- And last, we notice that there's still a blur for the areas where the brighter stars were (mainly 2-3 in this case). That is not only ok,is actually good. This is because one could expect that when we stretched our"MS" image, there might still be some residual flux from these stars in that image. By having a mask that gradually "protects" this area, we avoid to"reveal faint stuff" that is in fact, nothing but "glow" from a bright star.
With all this done, it is time to apply this mask to our original image.Areas in red are the areas that are being protected. Notice the "black islands"are gone but not so the bright spots over the few bright stars that are not protected.

All is left for us to do is to add back all of our previously broken down images:
- Our image with the small scale structures.
- Our image with the large but not so large scale structures.
- Our image with the very large scale structures.
We of course use PixelMath for that. The operation is a simple addition:SS+LS+MS. We must make sure the "Rescale result" option is active, so the result of this operation will produce an image within the allowed dynamic range.And because we're using a mask, any processing we've done in the separate images will only affect the areas unprotected by the mask.
As an alternative, we could use different formulas that I'll mention in a minute. And this is a closeup of our final image over the area we've targeted:

The difference from our original image is not dramatic. Yes, this is faint stuff and we want it to stay that way. We could have pushed the contrast in these areas of very faint dust to get a better view of the structures. The reason we didn't is because we didn't t want to make these structures as visible as the rest - that would indicate that the density of IFN in these areas is similar to that in other areas. This may be in fact a perfectly valid goal in some cases, enriching the documentary value of the image, but since for the entire image we've tried to keep a good "IFN density balance", we've decided not to break such balance this time.
Now, instead of the SS+LS+MS formula, we could have used other formulas that would tend to maximize or minimize the effect, using our own criteria. For example, instead we could have used:
-
Original+SS+LS+ML. This will minimize the processing done on this faint stuff by including the original image - remember, we're rescaling the result of this addition, so including the original image in the equation will produce a result more similar to the original image.
-
SS+LS+(MS*x) where x is a number that, if less than one, will also minimize the stretch done on that image, and if larger than one, it will emphasize it even more.
-
Same as above but using different ratios for each - or some - of the sub-images.
And other variations. Again, although a simple addition will probably give us a result in accordance to what we want, experimentation can be fun...
You may be wondering... If we only modified the MS image, why did we need to extract the intermediate LS image? Couldn't we just extract the SS and MS images so that they both add up nicely when they're put back together?
The answer is yes, we could have done that. The purpose of creating an intermediary large scale image is actually twofold:
-
First, it gives us a chance to experiment modifications in either or both of the LS and MS images. In this tutorial we finally didn't modify the LS image, but that's because we've skipped some of the"experimental" procedures that I did when processing the image. It was after experimentation using different methods that I decided to make modifications only on the MS image and not the LS image.
-
Second, even if we ended up not modifying the LS image, when we add everything back together, due to the fact we've considerably altered the luminosity of the MS image, if we were to add only the MS and SS images (assuming our LS image was the result of subtracting the original image from MS, which is not), the result would likely NOT be well balanced. By including an intermediate image, we help rebalancing the luminosity of the image. This is a similar effect to adding our scaled images along with the original.
5 - Data or artifacts?
There's a few things we can do to see whether this "dust" we now see is real or not. As a first step we're going to compare the image we started with against tour final image. To do that, we invert each of them, and then do an aggressive histogram adjustment to each image, separately, until both of them have similar intensity strength (meaning we'd have to go a bit further stretching the original image), then compare them:

We can see they look extremely similar, which means we haven't added anything to the final image that wasn't there before. We've simply made it a bit more visible, without inducing perceptible noise nor degrading the already bright structures in that area (in this case just stars) or anywhere else on the image.
However, this compares our original already-processed image with our result. We have not verified that the structures we've enhanced compare well with our data as it was when the image was still linear. To verify that, we will do the same but comparing the original linear image with the other two: the image we used before starting this session and our final image at the end of it:

As we can see, despite mainly qualitative details and some uncorrected seams and defects in the original linear image, the areas above the arches where the IFN intensity is higher seem to match nicely across all three images, in particular the 3-shaped cloud in the middle. Therefore the conclusion I reach is that this processing session yielded acceptable results and did not fabricate any non-existing signal.
6 - Wrap upThis tutorial shows one very simple way to use multi-scale processing. Someone could think that "all this" could have been reduced to create a duplicate layer, blur it, create a third layer with the difference,stretch the blurred layer it and "blend" it (add it) with the original and third layer while using a mask. If we want to simplify the description of the process, you could in fact say that, but the main difference is not only that eyeballing a Gaussian blur we could much easier induce unwanted and ambiguous "signal", but especially that by using wavelets we've operated under a much more controlled environment.
Having said that, the thing is that "all this" isn't complicated at all (I maybe made it look complicated by writing not only about what we do, but also why we do it, what other options we have, and a thinking process), but the fact is that "all this" can be wrapped up into four very simple steps:
- Break the image into small, and large scale structures
- Lightly stretch the image with the large scale structures
- Create a mask so the process only happens on the darkest areas of the image
- Add everything back together
For someone with some experience working with PixInsight, this session could be carried out in just 10 to 15 minutes.
The possibilities however go well beyond this, and depending on our goals, we could use this technique to do many very different tasks. For example, we could use wavelets over either the large or small scale images, to enhance the details at those scales. Or we could apply noise reduction over some - or all - of these images to attack noise at different scales (the ACDNR tool however is flexible enough to allow us doing that without us having to break down the image), adjust for saturation at different scales, and a very long etc.
|
Posted: May 6th, 2010
 Click here for a larger version
On Thursday May 6th, at Dino Pt, when I was "done" taking shots of my current project, I went for a quickie of this pair (M10 and M12) that despite they're not that far apart, I've never seen as a pair before.
Since I was just taking something without any preparation or plans, I first did a quick processing that resulted into a nice and simple image of these two globular clusters (800x532 version, 3779x2512 version).
Then I posted this version on a web forum and a couple of friends were quick to say "I stretched your image and I saw there's some of that dust we like so much". Funny, because when processing the luminance I too I did notice a few "odd" structures that I knew couldn't be gradients,
Anyway, this area is rather close to the Milky Way, so it makes sense there's "stuff" in the FOV, so I reprocessed it. I wasn't completely happy with the results so a couple of nights later at DeepSky Ranch I decided to capture more luminance, this time 7 subs of 15 minutes each. The "dusty" result is what you can see above. The image isn't as contrasty and probably less appealing to some than the original version, but for those into this type of thing I think it's kind of cool. The structures aren't as well defined as they should because the data is still somewhat marginal and this stuff is really faint.
Get a poster, t-shirt, mug, mousepad... with this image!
[ Hide image details]
|
DATE May 6th, 2010
PHOTO Exposure: L: 3 x 10' + 7 x 15', RGB: 3x5' each, Total: 3 hours Focal: 385mm, f/3.6 |
EQUIPMENT Imaging Scope: FSQ 106 EDX w/Reducer Camera: STL11k Guide Camera: StarShoot Autoguider Mount: EM-400
|
SITE & CONDITIONS Dinosaur Point and DeepSky Ranch, California Seeing: Terrible Transparency: Good
SOFTWARE Stacking: DeepSkyStaker Processing: PixInsight & Photoshop
|
|
Previous posts in May 2010
|