PhotometricMosiac 4.0

Hi John and thanks for the suggestion.

I found an old DSLR image of M31. It's not a full overlap:

View attachment 12153


so when I got to step 3 above, PMM gave me the message:
View attachment 12152

Noting your response to Wei-Hao, I did not take this option, so what should I do? I've tried ImageSolver as a pre-requisite to MosaicByCoordinates but it can't solve the DSLR image. I assume the registration process has upscaled its pixel resolution to match my main image so I entered the same resolution in ImageSolver.
OK so I allowed it to switch to Replace/Update and it ran through. It's delivered an improved result to the RGB combination, but the bottom-left triangle where the widefield image doesn't cover is still awful.
I guess the best thing will be to take a fresh widefield image. I think that's the only way I'm going to get a linear one.
 
Hi John and thanks for the suggestion.

I found an old DSLR image of M31. It's not a full overlap:

View attachment 12153


so when I got to step 3 above, PMM gave me the message:
View attachment 12152

Noting your response to Wei-Hao, I did not take this option, so what should I do? I've tried ImageSolver as a pre-requisite to MosaicByCoordinates but it can't solve the DSLR image. I assume the registration process has upscaled its pixel resolution to match my main image so I entered the same resolution in ImageSolver.
I will have a look at the code to see if this can be made to work more easily. I will report back in a few days time.
In the mean time, you could try NormalizeScaleGradient, using the DSLR image as the reference.
 
OK so I allowed it to switch to Replace/Update and it ran through. It's delivered an improved result to the RGB combination, but the bottom-left triangle where the widefield image doesn't cover is still awful.
I guess the best thing will be to take a fresh widefield image. I think that's the only way I'm going to get a linear one.
That sounds like the best option. (y)
 
Hi Wei-Hao
This problem arises because you are working on the unregistered target images. To solve this problem:
  1. Use MosaicByCoordinates to register all your target images AND the wide field image. Add the wide field image as the last item in the MosaicByCoordinates' list. This is necessary because the first image is used to determine the angle of the mosaic, and we need your tiles to be approximately horizontal / vertical.
  2. Use the registered wide field image as the reference image.
  3. Use the 'Target' mode for each registered mosaic tile.
John Murphy

[Edit]
An alternative that would work with your unregistered mosaic tiles would be to use NormalizeScaleGradient. Set the reference to the wide field image (registered to your mosaic tile) and add your mosaic tile as the only target image. The gradient surface spline is then fully interpolated across the whole of the target image. The only snag is you cannot apply different levels of smoothing for the overlap and the rest of the target image. However, with only small strips outside the overlap, this might work well. It may even be the best option for a corner tile.

Hi John,

Thank you for pointing me to NormalizeScaleGradient. I was aware of this script, but did not realize that it can be used this way. The Photometric Mosaic and MosaicByCoordinates route need coordinate information, which requires additional steps to come up. So I took the NormalizeScaleGradient route. It works, and it seems to run much faster than Photometric Mosaic (whose last step takes very long time). In general, I probably would say that NormalizeScaleGradient serves me better than Photometric Mosaic, simply from the speed point of view. For the very simple task that I am doing (matching a mosaic panel to a wide-field reference, provided that they are already registered), do you think there are any reasons to favor Photometric Mosaic over NormalizeScaleGradient?

On the other hand, I do find NormalizeScaleGradient has its limits (and I believe you are aware about them). First, it does not accept TIFF files as input, while Photometric Mosaic does. Also, even with FITS or XISF inputs, NormalizeScaleGradient doesn't work with integers (16 or 32 bit). Only after I saved my original TIFF to floating point XISF, NormalizeScaleGradient produced sensible results. I wonder if it is possible for you to make NormalizeScaleGradient accept TIFF files in the next release. (I know I am a outlier here. My workflow is mostly based on TIFF once the subs are calibrated and stacked.)

Finally, let me share what I got so far. Below is a "preview" of the final product. It had just gone through very quick and dirty mosaicking and post processing after the panels are matched with Photometric Mosaic or NormalizeScaleGradient. There are still many days of works before I feel comfortable to show people the full resolution version in a public place. But anyway, I am very happy with what I got so far, thanks to your scripts. My previous workflow relied on Photoshop and Registar to do the gradient removal and panel matching to the wide-field reference. This worked for years, until this one. Some of the panels here don't have sufficient S/N and sufficiently strong nebula features (above the noise floor) for Registar to perform the matching correctly. The high precision photometry of your scripts allows for the gradient matching of these low S/N panels, and this saves me. Thank you very much.

Cheers,
Wei-Hao

test2.jpg
 
Hi John,

Thank you for pointing me to NormalizeScaleGradient. I was aware of this script, but did not realize that it can be used this way. The Photometric Mosaic and MosaicByCoordinates route need coordinate information, which requires additional steps to come up. So I took the NormalizeScaleGradient route. It works, and it seems to run much faster than Photometric Mosaic (whose last step takes very long time). In general, I probably would say that NormalizeScaleGradient serves me better than Photometric Mosaic, simply from the speed point of view. For the very simple task that I am doing (matching a mosaic panel to a wide-field reference, provided that they are already registered), do you think there are any reasons to favor Photometric Mosaic over NormalizeScaleGradient?

On the other hand, I do find NormalizeScaleGradient has its limits (and I believe you are aware about them). First, it does not accept TIFF files as input, while Photometric Mosaic does. Also, even with FITS or XISF inputs, NormalizeScaleGradient doesn't work with integers (16 or 32 bit). Only after I saved my original TIFF to floating point XISF, NormalizeScaleGradient produced sensible results. I wonder if it is possible for you to make NormalizeScaleGradient accept TIFF files in the next release. (I know I am a outlier here. My workflow is mostly based on TIFF once the subs are calibrated and stacked.)

Finally, let me share what I got so far. Below is a "preview" of the final product. It had just gone through very quick and dirty mosaicking and post processing after the panels are matched with Photometric Mosaic or NormalizeScaleGradient. There are still many days of works before I feel comfortable to show people the full resolution version in a public place. But anyway, I am very happy with what I got so far, thanks to your scripts. My previous workflow relied on Photoshop and Registar to do the gradient removal and panel matching to the wide-field reference. This worked for years, until this one. Some of the panels here don't have sufficient S/N and sufficiently strong nebula features (above the noise floor) for Registar to perform the matching correctly. The high precision photometry of your scripts allows for the gradient matching of these low S/N panels, and this saves me. Thank you very much.

Cheers,
Wei-Hao

test2.jpg
I have posted a new version of NormalizeScaleGradient here:

I am hoping this will work with TIF files and should work with integer format. Could you either test this for me, or post a link to a reference and target image that showed the integer format problem.
Thanks, John Murphy
 
I have posted a new version of NormalizeScaleGradient here:
I am hoping this will work with TIF files and should work with integer format. Could you either test this for me, or post a link to a reference and target image that showed the integer format problem.
Thanks, John Murphy

Cool! I can confirm that it works on my 16bit TIFF. Thanks for this.
 
For the very simple task that I am doing (matching a mosaic panel to a wide-field reference, provided that they are already registered), do you think there are any reasons to favor Photometric Mosaic over NormalizeScaleGradient?
There are some minor differences:
  • NSG has been optimized for speed. In theory this could mean a very slight reduction in how accurately the surface spline is applied. However, I doubt the difference is ever noticeable.
  • NSG allows the surface spline to extend beyond the edge of the overlap. This is usually a good thing provided that the overlap area is large and the 'rest of the target image' (the target image beyond the overlap area) is small. This also allows better corrections at corners.
  • PhotometricMosaic terminates the surface spline at the boundary, and then propagates the gradient on the target side edge over the rest of the target image. The reason it does this is that for most mosaics, the overlap is long and thin. A thin overlap does not give a good indication of the real gradient perpendicular to the overlap strip. Allowing the surface spline to extend over the whole area could therefore produce very poor results if the thin strip suffered from local variations.
When using a wide field image to correct the gradients within the individual high resolution tiles, I would expect NSG to produce very good results.
 
I have a question here regarding photometric mosaic or normalize scale gradient.

What if the wide-field reference is taken with a lens with chromatic aberration? Worse, what if the chromatic aberration is coupled with some field curvature so stars in the center can have green fringes while stars in the corners can have purple fringes (for example)? Will this impact the photometric matching or the gradient removal?
 
I have a question here regarding photometric mosaic or normalize scale gradient.

What if the wide-field reference is taken with a lens with chromatic aberration? Worse, what if the chromatic aberration is coupled with some field curvature so stars in the center can have green fringes while stars in the corners can have purple fringes (for example)? Will this impact the photometric matching or the gradient removal?
Fortunately, stellar photometry doesn't need sharp stars. As long as the majority of the star light is within the inner measurement aperture, and the amount of star light within the outer aperture is negligible, all is well.

With NSG, the situation is even better, because for each star, the measurement is usually in the same part of the field of view, so both stars suffer from the same distortions and aberrations. We are only looking for a relative measurement, so any errors will cancel.

You can test how well it is working by using the Photometry Stars dialog; increase the 'Radius add' (inner measurement aperture) and 'Aperture gap' (the space between the inner and outer apertures). You will probably find that the points move slightly up or down the photometry graph line, but that the line gradient is hardly affected at all (the gradient of this line indicates the scale measurement).
1634293216172.png


The gradient correction algorithm is carefully designed to be resilient against different star profiles and color aberrations. This is achieved by using a grid of samples, median measurements and star rejection circles.

Regards, John Murphy
 
Last edited:
1636729429041.png


This major new version is included in the new PixInsight 1.8.8-10 release.
I provide this software for free, and dedicate a great deal of time and effort to write, update and support it. To continue to do this, I need your help and support. If you find my software useful, please 'buy me a coffee' (a small donation) at https://ko-fi.com/jmurphy It will be really appreciated. Thanks!

Major changes include:
  • The previous version needed the reference frame to have horizontal / vertical sides. If this condition was not met, bright or dark bands could be introduced on the target side of the join. This was particularly common in multi panel mosaics, because previous joins tend to leave a jagged edge. A significant amount of code was rewritten to fix this.
  • The way the join works has been simplified. On the target side of the join, the gradient correction smoothly tapers from the detailed gradient correction over the overlap region, to the smoother correction over the rest of the target image. On the reference side of the join, for 'Blend' or 'Average' combination modes, the join area is used to gradually change the noise or texture of the image from 100% reference, smoothly changing to 100% target at the join. The join area is now specified as a percentage of the distance between the join position and the reference side of the overlap.
  • To avoid discontinuities in the tapers described above, the join path never changes direction from the horizontal / vertical by more than 45 degrees.
  • In the previous version, if the reference and target star profiles differed, or the star alignment was poor due to distortions, the Blend mode could create speckle artifacts. The Average mode could create 'double' stars. The Outlier control has been introduced to cure this. Increase its value until the artifacts disappear. Values normally need to be between 1 and 10%. If the value is too high, a change in texture / noise may become visible along the center line of the join area.
  • If Mask is selected, a mask is created of the join. This is used to indicate where the join is to help evaluate how good the join is. This mask is now automatically applied to the output mosaic image. Use Ctrl + K to view/hide the mask (or Mac / Linux equivalent). The mask shows the join area (Blend or Average mode) or join line (Overlay mode), and the end of the target side taper (a fainter line).
1636730850411.png

  • The 'Join Size and Position' shows the overlap region. The reference and target images are displayed either side of the join (bright green line). They are roughly matched for display purposes by using an unlinked STF. The end of the join area (Blend or Average mode) is shown by the darker green line. The aim is to place the join in a 'quiet' area of the image. If possible, try to avoid areas of high contrast, image corners and edges. The join area usually wants to be quite large, but with a small margin between it and the edge of the overlap region. The default join area 'Size %' of 90% usually works well. The sample grid can be toggled on/off. Try to keep the join line within the grid area.
  • The position of the join can either be set with the Position (+/-) control, or by double clicking on the image.
1636732065859.png

  • The 'Adjust Scale' dialog can significantly improve the final result. This is used to fix scale errors. Why are there scale errors? The mosaic tiles are integrated images. Due to data rejection, ImageIntegration might not conserve star flux. This can introduce a scale error. To fix this, use the 'Gradient Path' control to position the green line over a bright and contrasty area of the image (or double click on the image). Then select 'Adjust Scale' section to view the graph.
  • The blue circles indicate where gradient samples are being rejected due to their proximity to bright stars. This can sometimes be seen as gaps in the graph.
1636732438078.png

If there is a scale error, the bright part of the image will form a peak or trough instead of following the general gradient trend. In this example, as the L/Red scale value is reduced, the peak will gradually disappear. If the value is reduced too much, a trough appears on the other side. Once the bright area follows the gradient trend, the scale is correct. This graph is extremely sensitive to scale errors. Care is needed though. If a peak/trough is not obvious, leave the control at 1.0; otherwise you may risk creating large scale errors.
1636732863901.png

In this case, no adjustment was needed. A scale correction factor of 1.0 gets rid of the peak / trough.


1636733947468.png

  • The Gradient graphs (overlap region and target region) are now also able to display an image of the overlap. The join is drawn as a green line. The blue circles (gradient graph for the rest of the target image) or red circles (gradient graph for overlap region) indicate where gradient samples are being rejected due to their proximity to bright stars. This can sometimes be seen as gaps in the graph. This provides some context to the graph. However, if you wish to change the join position, you need to go back to the 'Join Size and Position' dialog.
  • Deselect the 'Display image' check box to return to the graph.
  • Adjust the Overlap Gradient Graph so that it follows the gradient closely, but avoid following the noise.
  • Adjust the Target Gradient Graph so that it only follows the gradient trend. It should be a smooth gentle curve. This curve should be smooth enough so that the curvature does not change direction.
1636734249504.png

  • I now display the focal length and pixel size that was read from the FITS header. These are used to calculate many of the 'Auto' default values. The 'Image scale' button allows the user to override these values. These 'Auto' values rarely need to be changed by the user, so if all the parameters in a section are using their auto value, I collapse the section. The user can then concentrate on the important settings.
  • I now automatically save all the settings on exit. If you wish to return to the defaults, use the reset button at the bottom. When the reference / target images are changed, some settings will no longer make sense. These are then set back to their defaults.
I think that captures most of the changes! If you fail to produce a really good mosaic, let me know and I will try to help.
Regards, John Murphy

The script is now attached to:
 
Last edited:
John, I have been using PMM with panels that have been generated using the NSG script. Thanks for both, by the way, and enjoy your coffee!
When doing gradient reduction, I am doing it on the completed mosaic. I am assuming this is the correct way, or should I gradient-reduce each panel before creating the mosaic? I suppose I could just experiment and see for myself, but being lazy I thought I would just go to the font of knowledge!
 
John, I have been using PMM with panels that have been generated using the NSG script. Thanks for both, by the way, and enjoy your coffee!
When doing gradient reduction, I am doing it on the completed mosaic. I am assuming this is the correct way, or should I gradient-reduce each panel before creating the mosaic? I suppose I could just experiment and see for myself, but being lazy I thought I would just go to the font of knowledge!
You either need to correct the gradients before you register the images, or wait and correct the completed mosaic.

If you try to correct the registered images, you will end up with 'almost black' areas around your images, which would need to be removed (for example with PixelMath). Almost black areas will make the mosaic fail.

The best approach will depend on your data. With a mosaic of the Andromeda Galaxy, for example, it would be difficult to correct the individual tiles. So any corrections must be done in the final image. A mosaic of the Cygnus Loop / veil nebula is likely to have plenty of places for background samples in all the tiles. So you can then decide to correct before registering the mosaic tiles, or wait until completion. If you correct before registering, if the gradient is due to light pollution and not your flat field, make sure you use subtract (not division) as the correction method in DBE.

Thanks for the coffee, it really is appreciated :)
 
Last edited:
PhotometricMosaic 3.4.1 is now available via a PixInsight -10 update.

1637331770737.png

Improvements:
  • Color image star detection is now 3 times faster and more sensitive to faint stars.
  • Added Replace reference image check box. By replacing the reference image instead of creating a new one, more of the process history can be preserved. This can then be saved within an .xisf file.
  • The Replace Region option has been improved. This include a bug fix, and the ability to use a mask. This option can be used with any image (not just a mosaic) to copy a rectangle from the 'Target view' to the 'Reference view'. The copied rectangle is corrected for scale and gradient before overwriting this rectangular area in the reference frame. The copied pixels can be controlled with a mask.
For details of the functions that were added in 3.4.0, see:
 
Last edited:
This update improves star detection. Previously some bright stars could be missed. This will now happen less often.
 
Will this version be included in the next PI update?
Yes.

I am currently updating the Reference Documentation for NormalizeScaleGradient, which should also be in the release.

After that, I need to update the PhotometricMosaic documentation, which is now very out of date, especially the Quick Start Guide. Unfortunately this reference documentation will probably be too late for the coming release.
 
Hello, I'm running into an issue on MAC OS. I tried restarted Pixinsight but got the same message. This is happening when doing Calculation Scale.
Image 11-12-2021 at 18.42.jpg
 
Back
Top