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
306
141
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
306
141
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
75
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
306
141
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
75
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
306
141
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