PhotometricMosiac 3.3

PHannah

Well-known member
May 7, 2014
47
2
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.
 

jmurphy

PTeam Member
Jun 13, 2010
326
149
Basingstoke, England
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.
 

jmurphy

PTeam Member
Jun 13, 2010
326
149
Basingstoke, England
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)
 

whwang

Well-known member
Nov 6, 2012
78
3
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

 
  • Like
Reactions: jmurphy

jmurphy

PTeam Member
Jun 13, 2010
326
149
Basingstoke, England
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

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
 

whwang

Well-known member
Nov 6, 2012
78
3
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.
 
  • Like
Reactions: jmurphy

jmurphy

PTeam Member
Jun 13, 2010
326
149
Basingstoke, England
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.
 
  • Like
Reactions: whwang

whwang

Well-known member
Nov 6, 2012
78
3
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?
 

jmurphy

PTeam Member
Jun 13, 2010
326
149
Basingstoke, England
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: