Basic Questions on Shooting, Stacking and Stitching NIghtscapes

Hoka Hey

Senior Member
Messages
3,057
Solutions
1
Reaction score
2,173
Location
Asheville, NC, US
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?

2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?

4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.

Thanks in advance.

Joe
 
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?
Maximum exposure time for a single exposure will depend on a variety of factors like how dark your site is, how fast your lens is, what ISO you shoot at, and the declination of the field you are shooting as stars trail less near the poles. If you shoot with really wide lenses, you will have different trail lengths in the frame.

In general shorter exposures work better for your purpose because the star trails will be shorter.
2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?
No.

It with the square root of the number of frames stacked... so for 2 frames it is 1.414x improvement compared to a single frame.

For 4 frames it is 2x improvement over a single frame. For 9 you get 3x. For 16 your get 4x improvement.,, over a single frame.

But if you go from 4 frames to 8 frames, it is only a 1.414x improvement compared to 4 frames (remember, 8 frames is only a 4x improvement compared to a single frame)...

So, comparing 4 frames to 8 frames, the square root of 4 is 2, and the square root of 8 is 2.828.

2 / 2.828 is 1.414x for 4 frames compared to 8.
3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?
Again, it depends on how dark your sky is, how wide your field is, how much you are willing to crop off, how much trailing you can tolerate, how well the software handles the trailing... etc.
4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.
Depends on how well your stacking and aligning program can deal with the coma and how much overlap you have and if the program can deal with less overlap.

You don't really have enough info for your questions to be answered in general... you will undoubtedly have to experiment to see what you can get away with.

Jerry
 
Last edited:
Depends on how well your stacking and aligning program can deal with the coma and how much overlap you have and if the program can deal with less overlap.

You don't really have enough info for your questions to be answered in general... you will undoubtedly have to experiment to see what you can get away with.

Jerry
Thank you Jerry for your thoughtful response and for setting me straight on the benefits of additional exposures in stacking.

I am doing a lot of experimenting to find what works best, but am not too proud to ask for help from more experienced photographers like you.

For nightscapes, I am using a Canon 5d mk iv with a Canon 35mm 1.4 mk ii and a Sigma 14mm 1.8. I will also be experimenting with my Canon 50mm 1.2 and my 85mm 1.2 to find out what I can get out of them. From what I have been able to do so far, the 35mm seems to do the best job of the Canon lenses for nightscapes.

Currently, I'm trying to get technique down and am going to convenient "dark" sites. Once I figure out the best combination of equipment and software, I will spend more time and effort locating dark sites with interesting foregrounds.

The image below represents my best effort so far. It was done with the 35mm. The jpg below is terrible. The full-size jpg is better, but not as good as the TIF. I have no idea how to convert a nice sharp TIF to a decent looking JPG for this site.

Thanks again for all your help.

Joe





Link to full-size JPG.
 

Attachments

  • 3764925.jpg
    3764925.jpg
    10.1 MB · Views: 0
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?

2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?

4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.

Thanks in advance.

Joe
Regarding #4..

imo Yes.. I imported a stack of RAW images to sequator and was not particualrly impressed with the output.. So in ACDSee (quicker than LR) I created a develop process that uses the camera/lens profile (which eliminated edge issues of non geometric stars & coma), removed a residual mild vignette and some basic wb adjustment. I applied this to the entire stack of images plus darks and exported the bunch to tiff - for import to sequator. The resultant stacked image was greatly improved.

To my thought process, like any software, garbage in = garbage out, and given you easily have the ability to remove lens issues before the fact, batch processing the entire set of images gives a far better starting point for the stacking software to work with
 
Milkyway shots are awesome when the sky is dark enough.

I tried some with the 6D and Samyang 14.



45x30sec steady camera Samyang 14mm set to f/4 stacked and postprocessed with PS.
45x30sec steady camera Samyang 14mm set to f/4 stacked and postprocessed with PS.

And single frames can be nice as well.

Single 30 sec image Samyang 14 set to f/4 with moonlit clouds
Single 30 sec image Samyang 14 set to f/4 with moonlit clouds



--
Ricoh KR-5 ... Pentax ME Super ... Canon T90 ... ... ... 40d ... 7d ... 6d
 
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?

2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?

4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.

Thanks in advance.

Joe
Regarding #4..

imo Yes.. I imported a stack of RAW images to sequator and was not particualrly impressed with the output.. So in ACDSee (quicker than LR) I created a develop process that uses the camera/lens profile (which eliminated edge issues of non geometric stars & coma), removed a residual mild vignette and some basic wb adjustment. I applied this to the entire stack of images plus darks and exported the bunch to tiff - for import to sequator. The resultant stacked image was greatly improved.

To my thought process, like any software, garbage in = garbage out, and given you easily have the ability to remove lens issues before the fact, batch processing the entire set of images gives a far better starting point for the stacking software to work with
This may be okay in ACDSee (I know nothing about it), but as Mark Shelley has found, do not try it in Lightroom. You want to be stacking linear data, and after running through LR, it will no longer be linear, with skewed color ratios.
 
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?
You would be surprised how well some software can do this. Give the trial of Astro Pixel Processor a try.
 
Last edited:
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?

2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?

4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.

Thanks in advance.

Joe
Regarding #4..

imo Yes.. I imported a stack of RAW images to sequator and was not particualrly impressed with the output.. So in ACDSee (quicker than LR) I created a develop process that uses the camera/lens profile (which eliminated edge issues of non geometric stars & coma), removed a residual mild vignette and some basic wb adjustment. I applied this to the entire stack of images plus darks and exported the bunch to tiff - for import to sequator. The resultant stacked image was greatly improved.

To my thought process, like any software, garbage in = garbage out, and given you easily have the ability to remove lens issues before the fact, batch processing the entire set of images gives a far better starting point for the stacking software to work with
This may be okay in ACDSee (I know nothing about it), but as Mark Shelley has found, do not try it in Lightroom. You want to be stacking linear data, and after running through LR, it will no longer be linear, with skewed color ratios.
Sorry for any confusion.. I was actually not suggesting stacking in LR, simply batch processing the RAW files and exporting them to 16 bit tif.. These are then subsequently stacked in software of choice.

Consider this a pre-process to stacking, one that gives the stacking software the best possible input to work with... therefore ANY raw developer capable of batch processing and tif export is suitable...in my case with both LR and ACDSee, i use ACDSee as it is not just faster, it requires no import.
 
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?

2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?

4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.

Thanks in advance.

Joe
Regarding #4..

imo Yes.. I imported a stack of RAW images to sequator and was not particualrly impressed with the output.. So in ACDSee (quicker than LR) I created a develop process that uses the camera/lens profile (which eliminated edge issues of non geometric stars & coma), removed a residual mild vignette and some basic wb adjustment. I applied this to the entire stack of images plus darks and exported the bunch to tiff - for import to sequator. The resultant stacked image was greatly improved.

To my thought process, like any software, garbage in = garbage out, and given you easily have the ability to remove lens issues before the fact, batch processing the entire set of images gives a far better starting point for the stacking software to work with
This may be okay in ACDSee (I know nothing about it), but as Mark Shelley has found, do not try it in Lightroom. You want to be stacking linear data, and after running through LR, it will no longer be linear, with skewed color ratios.
Sorry for any confusion.. I was actually not suggesting stacking in LR, simply batch processing the RAW files and exporting them to 16 bit tif.. These are then subsequently stacked in software of choice.

Consider this a pre-process to stacking, one that gives the stacking software the best possible input to work with... therefore ANY raw developer capable of batch processing and tif export is suitable...in my case with both LR and ACDSee, i use ACDSee as it is not just faster, it requires no import.
That's what I mean - preprocessing in LR will change the data from linear to non-linear. Stacking software assumes linear and you will not get the correct output. If Mark is around he could explain further. Basically, any steps that would alter the data to a non-linear state need to be done after stacking. Hopefully ACDSee can retain linearity.
 
Last edited:
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?

2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?

4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.

Thanks in advance.

Joe
Regarding #4..

imo Yes.. I imported a stack of RAW images to sequator and was not particualrly impressed with the output.. So in ACDSee (quicker than LR) I created a develop process that uses the camera/lens profile (which eliminated edge issues of non geometric stars & coma), removed a residual mild vignette and some basic wb adjustment. I applied this to the entire stack of images plus darks and exported the bunch to tiff - for import to sequator. The resultant stacked image was greatly improved.

To my thought process, like any software, garbage in = garbage out, and given you easily have the ability to remove lens issues before the fact, batch processing the entire set of images gives a far better starting point for the stacking software to work with
This may be okay in ACDSee (I know nothing about it), but as Mark Shelley has found, do not try it in Lightroom. You want to be stacking linear data, and after running through LR, it will no longer be linear, with skewed color ratios.
Sorry for any confusion.. I was actually not suggesting stacking in LR, simply batch processing the RAW files and exporting them to 16 bit tif.. These are then subsequently stacked in software of choice.

Consider this a pre-process to stacking, one that gives the stacking software the best possible input to work with... therefore ANY raw developer capable of batch processing and tif export is suitable...in my case with both LR and ACDSee, i use ACDSee as it is not just faster, it requires no import.
That's what I mean - preprocessing in LR will change the data from linear to non-linear. Stacking software assumes linear and you will not get the correct output. If Mark is around he could explain further. Basically, any steps that would alter the data to a non-linear state need to be done after stacking. Hopefully ACDSee can retain linearity.
This is not true. Stacking makes no assumption--it simple stacks, e.g. median, sigma clipped average.
 
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?

2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?

4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.

Thanks in advance.

Joe
Regarding #4..

imo Yes.. I imported a stack of RAW images to sequator and was not particualrly impressed with the output.. So in ACDSee (quicker than LR) I created a develop process that uses the camera/lens profile (which eliminated edge issues of non geometric stars & coma), removed a residual mild vignette and some basic wb adjustment. I applied this to the entire stack of images plus darks and exported the bunch to tiff - for import to sequator. The resultant stacked image was greatly improved.

To my thought process, like any software, garbage in = garbage out, and given you easily have the ability to remove lens issues before the fact, batch processing the entire set of images gives a far better starting point for the stacking software to work with
This may be okay in ACDSee (I know nothing about it), but as Mark Shelley has found, do not try it in Lightroom. You want to be stacking linear data, and after running through LR, it will no longer be linear, with skewed color ratios.
Sorry for any confusion.. I was actually not suggesting stacking in LR, simply batch processing the RAW files and exporting them to 16 bit tif.. These are then subsequently stacked in software of choice.

Consider this a pre-process to stacking, one that gives the stacking software the best possible input to work with... therefore ANY raw developer capable of batch processing and tif export is suitable...in my case with both LR and ACDSee, i use ACDSee as it is not just faster, it requires no import.
That's what I mean - preprocessing in LR will change the data from linear to non-linear. Stacking software assumes linear and you will not get the correct output. If Mark is around he could explain further. Basically, any steps that would alter the data to a non-linear state need to be done after stacking. Hopefully ACDSee can retain linearity.
This is not true. Stacking makes no assumption--it simple stacks, e.g. median, sigma clipped average.
Roger is right. There is no real reason not to stack linear data unless you are taking an extreme purist viewpoint. There are a few things to look out for though:
  • PixInsight normalisation during stacking does assume the data are linear which can result in odd transformations to non-linear data, altering the colour balance. The stated purpose of this is to make the whole data set statistically compatible. So switch off normalisation for image combination.
  • Stacking programs may not preserve the embedded ICC profile in the stacked file that they generate. So if you export 16 bit TIFFs from Lightroom in, for instance, the Adobe RGB colour space there is a risk the stacked file will be treated as the default sRGB when you open it in Photoshop. This will affect the saturation of colours.
  • Again if you are interested in careful colour management then light pollution should not be subtracted from non-linear data. But this is not a stacking issue - it applies equally to unstacked data.
Mark

--
Takahashi Epsilon 180ED
H-alpha modified Sony A7S
http://www.markshelley.co.uk/Astronomy/
 
Last edited:
That's what I mean - preprocessing in LR will change the data from linear to non-linear. Stacking software assumes linear and you will not get the correct output. If Mark is around he could explain further. Basically, any steps that would alter the data to a non-linear state need to be done after stacking. Hopefully ACDSee can retain linearity.
This is not true. Stacking makes no assumption--it simple stacks, e.g. median, sigma clipped average.
Roger is right. There is no real reason not to stack linear data unless you are taking an extreme purist viewpoint. There are a few things to look out for though:
  • PixInsight normalisation during stacking does assume the data are linear which can result in odd transformations to non-linear data, altering the colour balance. The stated purpose of this is to make the whole data set statistically compatible. So switch off normalisation for image combination.
  • Stacking programs may not preserve the embedded ICC profile in the stacked file that they generate. So if you export 16 bit TIFFs from Lightroom in, for instance, the Adobe RGB colour space there is a risk the stacked file will be treated as the default sRGB when you open it in Photoshop. This will affect the saturation of colours.
Yes, I agree, but this is not a modification of the data, just the tag in the header. DSS loses the color space definition. The first thing I do when bringing the stacked image into the photo editor is to reassign the color space.
  • Again if you are interested in careful colour management then light pollution should not be subtracted from non-linear data. But this is not a stacking issue - it applies equally to unstacked data.
I agree that you are technically correct, but with proper care this is the best method with the tools available for most people to produce excellent color. And if people followed my guides, they could produce better and more consistent color, minimizing any issue with tone curve data. Unfortunately, there are far more destructive methods in wide use that destroy accurate color than simply working with tone curve data--the recent postings in this forum are good examples. The Rho Ophiuchus region images in particular are excellent examples of such problems that have nothing to do with working on tone curve data or not--they show variable color balance with scene intensity, and the amount of shift is variable throughout the scene! Pixinsight's background neutralization is an example that often destroys any hint of accurate color. Pixinsight DBE (I think that is what it is called) is another. We commonly see different images covering the entire rainbow of colors from red to blue to purple in night sky images and it has nothing to do with working with tone curve data or not. And unfortunately most linear astro linear processing software does not apply the color matrix corrections for digital camera data, leading to more color destructive methods being applied to try and bring out color.

Roger
 
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:

1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?

2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?

4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.

Thanks in advance.

Joe
Regarding #4..

imo Yes.. I imported a stack of RAW images to sequator and was not particualrly impressed with the output.. So in ACDSee (quicker than LR) I created a develop process that uses the camera/lens profile (which eliminated edge issues of non geometric stars & coma), removed a residual mild vignette and some basic wb adjustment. I applied this to the entire stack of images plus darks and exported the bunch to tiff - for import to sequator. The resultant stacked image was greatly improved.

To my thought process, like any software, garbage in = garbage out, and given you easily have the ability to remove lens issues before the fact, batch processing the entire set of images gives a far better starting point for the stacking software to work with
This may be okay in ACDSee (I know nothing about it), but as Mark Shelley has found, do not try it in Lightroom. You want to be stacking linear data, and after running through LR, it will no longer be linear, with skewed color ratios.
Sorry for any confusion.. I was actually not suggesting stacking in LR, simply batch processing the RAW files and exporting them to 16 bit tif.. These are then subsequently stacked in software of choice.

Consider this a pre-process to stacking, one that gives the stacking software the best possible input to work with... therefore ANY raw developer capable of batch processing and tif export is suitable...in my case with both LR and ACDSee, i use ACDSee as it is not just faster, it requires no import.
That's what I mean - preprocessing in LR will change the data from linear to non-linear. Stacking software assumes linear and you will not get the correct output. If Mark is around he could explain further. Basically, any steps that would alter the data to a non-linear state need to be done after stacking. Hopefully ACDSee can retain linearity.
This is not true. Stacking makes no assumption--it simple stacks, e.g. median, sigma clipped average.
Roger is right. There is no real reason not to stack linear data unless you are taking an extreme purist viewpoint. There are a few things to look out for though:
  • PixInsight normalisation during stacking does assume the data are linear which can result in odd transformations to non-linear data, altering the colour balance. The stated purpose of this is to make the whole data set statistically compatible. So switch off normalisation for image combination.
  • Stacking programs may not preserve the embedded ICC profile in the stacked file that they generate. So if you export 16 bit TIFFs from Lightroom in, for instance, the Adobe RGB colour space there is a risk the stacked file will be treated as the default sRGB when you open it in Photoshop. This will affect the saturation of colours.
  • Again if you are interested in careful colour management then light pollution should not be subtracted from non-linear data. But this is not a stacking issue - it applies equally to unstacked data.
I was careful to say "stacking software", assuming that one would proceed with other operations after the actual stacking. I should have probably said astro processing software more generically.

But as usual, you are correct. Roger does have a point as well.
 
Last edited:
  • Again if you are interested in careful colour management then light pollution should not be subtracted from non-linear data. But this is not a stacking issue - it applies equally to unstacked data.
I agree that you are technically correct, but with proper care this is the best method with the tools available for most people to produce excellent color. And if people followed my guides, they could produce better and more consistent color, minimizing any issue with tone curve data. Unfortunately, there are far more destructive methods in wide use that destroy accurate color than simply working with tone curve data--the recent postings in this forum are good examples.
In my experience, the blind use of "Curves" transforms is the most common way to destroy colour. Colour preserving stretches should always be used in preference.
The Rho Ophiuchus region images in particular are excellent examples of such problems that have nothing to do with working on tone curve data or not--they show variable color balance with scene intensity, and the amount of shift is variable throughout the scene! Pixinsight's background neutralization is an example that often destroys any hint of accurate color. Pixinsight DBE (I think that is what it is called) is another.
The PIxInsight background extraction (ABE and DBE) and BN tools work correctly. However, as with any tool they can be abused and/or inexpertly applied.
We commonly see different images covering the entire rainbow of colors from red to blue to purple in night sky images and it has nothing to do with working with tone curve data or not. And unfortunately most linear astro linear processing software does not apply the color matrix corrections for digital camera data, leading to more color destructive methods being applied to try and bring out color.
Ignoring the colour matrix is generally no worse for colour than subtracting skyglow from variable gamma tone curve data. But to achieve consistent and accurate colour rendition it is necessary to both use the colour matrix and to subtract skyglow from data in its linear form.

It is also worth pointing out that subtraction of skyglow from non-linear data itself leads to variable colour balance with scene intensity and that a variable gamma tone curve leads to variable colour saturation with scene intensity. I noted these effects here: http://www.markshelley.co.uk/Astronomy/Processing/ACR_Critique/acr_critique.html

Mark
 
Last edited:
When shooting stacks to be merged into a mosaic of a nightscape on a fixed mount:
Not sure you got all your questions covered.
1. Please confirm that it is better to shoot a larger number of shorter exposure shots using Roger Clark's Rule of 200 than a lower number of longer exposure shots?
I also uses SLS often for stacking. Haven't studied some recent updates. Sometimes geometric distortion will limit how many images can be stacked with WA & UWA lenses. This will depend on how good the lens profile geometric distortion correction is. They are often incomplete leaving uneven residual distortion. Its my understanding this is one of the strengths of the Windows stacker Sequator, it adjust the manages to align correctly even w/ residual distortion. With my Olympus MZ 12mm f2, couldn't stack more than about 8x 20 sec. images.

Definately make a vignette correction during RAW development of all the images to be stacked. Roger's basic workflow recommendations can tell you what to do here.
2. Is it correct that the improvement of quality derived from stacking double from 1 image to 2, 2 to 4, 4 to 8, 8 to 16, etc.?

3. It seems like that the more the stars move the harder it becomes to stitch together a mosaic of stacked images for an accurate image of the nightscape. If so, what is that sweet spot for the number of stacked images?
I've never had a starry landscape image I couldn't stitch w/ PTGui even when images are widely separated in time & there is lot of star movement if I've overlapped images by 20-30%. Certainly had hard to stitch images when overlap was <20%.
4. Let's say you have a lens with slight coma in the corners and vignetting. Does it make sense to import each entire stack into ACR, select all and crop the edges to cut off the stars with coma before proceeding with the rest of your workflow? I'm using Starry Landscape Stacker for stacking and PS for merging the panorama.
In general I would not crop images before stitching. If coma at the edges is uneven due to decentering, you might have to however because it could be hard to accurately stitch when trying to match one side w/ little coma to another side w/ lots. Again having sufficient overlap will be important if the lens has decentering. The stitcher will mask out the fuzzzy edges.

I've often had problems stitching in PS not because of stitching errors but because the exposure blends leave obvious tracks in the sky regardless of amount of overlap. My success rate on starry landscapes w/ PS has been <50%. Instead, I create layers in PTGui & bring those into PS for blending land to sky & making final adjustments to color & etc.

If making a stars only moasiac stitch in PTGui & export into PS for final corrections.

Keep at it this is a rewarding area of photography.
Thanks in advance.

Joe
 
Last edited:

Keyboard shortcuts

Back
Top