PhotometricMosiac 4.0

In the last documentation update (in the zipped file), there is a file named "PhotometricMosaic.pidoc' and there is no longer a .html file.

I guess I may have missed something. What's the .pidoc intended use?
Oops! I posted the uncompiled reference documentation...
I have now replaced it with the compiled version. This contains the html file.


Install this to your PixInsight folder. For example, on windows, the installed files should include:
C:\Program Files\PixInsight\doc\scripts\PhotometricMosaic\PhotometricMosaic.html
C:\Program Files\PixInsight\doc\scripts\PhotometricMosaic\images\...
 
Last edited:
I have also made some minor updates to the PhotometricMosaic script. This will also be included in the PixInsight -12 release.
(This zip file also includes TrimMosaicTile and SplitMosaicTile, although those two scripts have not been changed.)
 
That sounds like the best option. (y)
Hi John

After 3 months waiting for decent weather, I have finally acquired a widefield image of M31 with my DSLR so am in a position to resume this processing project.

So to recap (mainly for my benefit) I now need to use PMM in Target mode with my widefield image (now registered to my mosaic) as the reference and apply it to each of my individual panels for each filter.
First problem is that when I start up PMM, no Target mode option appears - only Overlay, Blend and Average. I guess I'm doing something stupid, but can't see what it is?

Thanks
Peter.
 
Hi John

After 3 months waiting for decent weather, I have finally acquired a widefield image of M31 with my DSLR so am in a position to resume this processing project.

So to recap (mainly for my benefit) I now need to use PMM in Target mode with my widefield image (now registered to my mosaic) as the reference and apply it to each of my individual panels for each filter.
First problem is that when I start up PMM, no Target mode option appears - only Overlay, Blend and Average. I guess I'm doing something stupid, but can't see what it is?

Thanks
Peter.
I removed the Target mode, because there is now a better way of doing it.
Section 1.7 of the help file explains:

If a linear widefield image of the mosaic area is available, this can be used as a template to remove the gradients from the individual tiles.

For each high resolution tile:

Crop the stacked mosaic tile back to good data.
Use StarAlignment to register a copy of the widefield image to the tile.
Use the NormalizeScaleGradient script, setting the registered widefield image as the reference, and the high resolution mosaic tile as the target.
Use the NSG corrected tiles to create the mosaic (ImageSolver, MosaicByCoordinates, TrimMosaicTile, PhotometricMosaic). The result will have the same gradients as the linear widefield image, but it should no longer be lumpy. The remaining gradient should be much easier to fix.


Note that you need to use StarAlignment and NSG before doing the mosaic registration.
Let me know if anything is unclear. I find that writing help files is a tricky challenge.
 
Thanks John, that explains it!

So just to be clear, I am hoping I can still use my stacked panel files I made in September (i.e. I don't need to go back to the individual files and re-integrate them)? - as there are 40 of them.

Also, I registered my widefield image to my previously constructed Lum mosaic - is this OK? or does the widefield image need to be registered to each of the panels in turn (all 5 filter mosaics are co-registered)?

Thanks
Peter.
 
So just to be clear, I am hoping I can still use my stacked panel files I made in September (i.e. I don't need to go back to the individual files and re-integrate them)? - as there are 40 of them.
Correct, there is no need to restack the panels.
Wow, that is a lot of data!

Also, I registered my widefield image to my previously constructed Lum mosaic - is this OK? or does the widefield image need to be registered to each of the panels in turn (all 5 filter mosaics are co-registered)?
I am guessing that 24 of your stacks are R, G, B, and 16 are narrow band.
You should only normalize the R, G, B to the widefield image. In NSG, the reference and target must use the same filter.

For best results, for each of your 24 R, G, B stacks, register a copy of the widefield image to the stack. Then use NSG (reference is set to registered widefield image; the single target image is the corresponding stacked panel).
Then go through the full mosaic process (MosaicByCoordinates, TrimMosaicTile, PhotometricMosaic).
 
I am using latest version of PixInsight 1.8.8-12 and I am trying to use Photometric Mosaic but keep getting an error

PopUP Dialog Box
Code:
Error: Image.getSamples(): insufficient array elements

Log Window
Code:
Creating Mosaic

Writing swap files...

2710.506 MiB/s

Use [Ctrl+k] to show/hide the join mask.

Reference  [0] 100%

Target     [0]   0%

*** Error [000]: /home/smccully/PixInsight/src/scripts/JohnMurphy/mosaic/src/lib/Gradient.js, line 859: Error: Image.getSamples(): insufficient array elements

Reading swap files...

2646.390 MiB/s
 
I am using latest version of PixInsight 1.8.8-12 and I am trying to use Photometric Mosaic but keep getting an error

PopUP Dialog Box
Code:
Error: Image.getSamples(): insufficient array elements

Log Window
Code:
Creating Mosaic

Writing swap files...

2710.506 MiB/s

Use [Ctrl+k] to show/hide the join mask.

Reference  [0] 100%

Target     [0]   0%

*** Error [000]: /home/smccully/PixInsight/src/scripts/JohnMurphy/mosaic/src/lib/Gradient.js, line 859: Error: Image.getSamples(): insufficient array elements

Reading swap files...

2646.390 MiB/s


For some reason changing the target, and reference images appears to work though
 
I am using latest version of PixInsight 1.8.8-12 and I am trying to use Photometric Mosaic but keep getting an error

PopUP Dialog Box
Code:
Error: Image.getSamples(): insufficient array elements

Log Window
Code:
Creating Mosaic

Writing swap files...

2710.506 MiB/s

Use [Ctrl+k] to show/hide the join mask.

Reference  [0] 100%

Target     [0]   0%

*** Error [000]: /home/smccully/PixInsight/src/scripts/JohnMurphy/mosaic/src/lib/Gradient.js, line 859: Error: Image.getSamples(): insufficient array elements

Reading swap files...

2646.390 MiB/s
Could you send me a link to the registered reference image and target image? (Save the two images in the .xisf format, specifying compression - the black areas compress really well).
Thanks, John
 
Correct, there is no need to restack the panels.
Wow, that is a lot of data!


I am guessing that 24 of your stacks are R, G, B, and 16 are narrow band.
You should only normalize the R, G, B to the widefield image. In NSG, the reference and target must use the same filter.

For best results, for each of your 24 R, G, B stacks, register a copy of the widefield image to the stack. Then use NSG (reference is set to registered widefield image; the single target image is the corresponding stacked panel).
Then go through the full mosaic process (MosaicByCoordinates, TrimMosaicTile, PhotometricMosaic).
Hi John

For some reason I am having great difficulty registering the widefield image to the first individual panel master. Typical messages in the process console are
* Reference image: Limiting to 1000 brightest stars.

* Distortion correction: Iteration 1 of 20

Matching stars: done

10 putative star pair matches.

Performing RANSAC: done

*** Error: Unable to find an initial set of putative star pair matches

I am using Star Alignment with working mode Register/Match images, I have tried both Projective Transformation and Thin Plate Splines (to enable me to check Distortion Correction), I have tried with and without Frame adaptation and I have increased the RANSAC tolerance to 7. Nothing is working.
Would it help if I re-scaled the widefield image to produce a similar pixel scale to my high-res panels? Or even cropped it to the approximate area covered by each panel in turn?

Thanks
Peter.
 
One option is to use the
I am using Star Alignment with working mode Register/Match images ...
Would it help if I re-scaled the widefield image to produce a similar pixel scale to my high-res panels? Or even cropped it to the approximate area covered by each panel in turn?
Yes, I think cropping the widefield image so that the area it covers is only a bit bigger than the high resolution image is probably the best option.

Alternatively, you could try adding a preview in the widefield image that is approximately the correct area. See https://pixinsight.com/forum/index....age-with-a-narrow-field-one.17850/post-108266

If this fails, the alternative would be to use DynamicAlignment. You would only need to match 3 stars. Cropping and resizing should not be necessary, but might make it easier to manually match the stars.

Let me know how you get on. If registration turns out to be really difficult, I may need to rethink the strategy.
Regards, John
 
I am using latest version of PixInsight 1.8.8-12 and I am trying to use Photometric Mosaic but keep getting an error

PopUP Dialog Box
Code:
Error: Image.getSamples(): insufficient array elements

Log Window
Code:
Creating Mosaic

Writing swap files...

2710.506 MiB/s

Use [Ctrl+k] to show/hide the join mask.

Reference  [0] 100%

Target     [0]   0%

*** Error [000]: /home/smccully/PixInsight/src/scripts/JohnMurphy/mosaic/src/lib/Gradient.js, line 859: Error: Image.getSamples(): insufficient array elements

Reading swap files...

2646.390 MiB/s
Bug confirmed and fixed.
I will upload it to PixInsight tomorrow so that it can be included in the next update.
Regards, John Murphy
 
One option is to use the

Yes, I think cropping the widefield image so that the area it covers is only a bit bigger than the high resolution image is probably the best option.

Alternatively, you could try adding a preview in the widefield image that is approximately the correct area. See https://pixinsight.com/forum/index....age-with-a-narrow-field-one.17850/post-108266

If this fails, the alternative would be to use DynamicAlignment. You would only need to match 3 stars. Cropping and resizing should not be necessary, but might make it easier to manually match the stars.

Let me know how you get on. If registration turns out to be really difficult, I may need to rethink the strategy.
Regards, John
I tried adding a preview and the registration worked straight away, so I'll now use that method for all my panels. My filters are LRGB Ha, so for the Lum I was planning to use ChannelExtraction on the widefield image to extract the L channel (in CIE L*a*b* mode). Do you agree with this approach?

For my Ha - which showed the worst gradients when I first assembled the mosaic - are you saying there is no way to use the widefield image?

Peter.
 
I tried adding a preview and the registration worked straight away, so I'll now use that method for all my panels.
I will update the Reference Documentation to include this.

My filters are LRGB Ha, so for the Lum I was planning to use ChannelExtraction on the widefield image to extract the L channel (in CIE L*a*b* mode). Do you agree with this approach?
Yes, good idea! You will need to ignore the warnings about the Filter FITS Header strings not matching. They are only warnings.

For my Ha - which showed the worst gradients when I first assembled the mosaic - are you saying there is no way to use the widefield image?
Usually the answer would be no. For example, normalizing a red image with a blue image would make no sense. We expect the red and blue image to be different. Hence the warnings built into NSG (target list drawn in red, console warnings).

There are two things you could try:

Try to create the mosaic with the Ha frames again. The latest release of PhotometricMosaic is much better at handling gradients than the previous versions. Then fix the final Ha result with DBE.

Or:

Normalize Ha to Red. The problem here is that the stellar photometry will get the wrong result - we expect the Ha stars to be fainter than the Red stars. With an incorrect scale, the emission nebula will be scaled differently (the emission nebula in the Ha will be strongly boosted). The algorithm will then think the Ha regions are light pollution, and try to remove them...

You can turn off the photometry (in the Photometry section) by setting the Filter photometry stars -> Limit stars% to zero. This then uses the mean and median to calculate the scale. I think this would work for an emission nebula, but probably not for a galaxy that is dominated by stars.

Either way, if the gradient smoothness is high enough, small localized emission nebula might not be affected too badly.

Or:

If nothing works, the final option: on a really good moonless night, collect a single Ha frame for each Ha panel. Use these images to normalize each Ha stack. Perhaps make a mosaic without the Ha first, and then add this improved Ha at a later date.

Hope this helps, John Murphy
 
Still wrestling with this but I've now been diverted by a strange thing I can't explain. My raw frames have a pixel size of 12.0 microns and my focal length is 2540mm. This is borne out by the FITS keywords on all my individual subs.
But when I examine my mosaic panels the pixel size has changed to 7.4 and the focal length to 1569, i.e. both have been reduced by a factor of 0.62 approx. It seems to have happened during the Mosaic By Coordinates step.
Is this normal/expected?
Thanks
Peter.
 
Still wrestling with this but I've now been diverted by a strange thing I can't explain. My raw frames have a pixel size of 12.0 microns and my focal length is 2540mm. This is borne out by the FITS keywords on all my individual subs.
But when I examine my mosaic panels the pixel size has changed to 7.4 and the focal length to 1569, i.e. both have been reduced by a factor of 0.62 approx. It seems to have happened during the Mosaic By Coordinates step.
Is this normal/expected?
Thanks
Peter.
I am guessing this occurred within ImageSolver. It requires either the focal length or the pixel size. If the value given is wrong, the image scale would still end up correct, but both the focal length and pixel size would end up wrong.
1642776224825.png

PhotometricMosaic is quite tolerant to pixel size or focal length errors. They are only used to determine 'Auto' defaults, and in any case, it often uses the image scale, which is still correct. So I would not worry too much, but you can override the header values with the 'Image scale' button:
1642776512330.png


Regards, John
 
I have has the same thing happened which also surprised me as my fits have correct FL and pixel size at the start. It doesn't matter but still odd.
 
I've been running PMM on some data I have on M42. The 90 second and 10 second panels work out fine, but I get this error when I am running the 3 second panels. Each panel is ImageSolved, registered in MosaicByCoordinates and trimmed, but PMM throws this error message. Not sure what to do. I was running 1.8.8-9; just updated to 8-12 and all the updates and same error. I will start all over again but in the meanwhile, does this give any clue as to what the problem is?
Screen Shot 2022-01-27 at 5.28.40 PM.png
 
I've been running PMM on some data I have on M42. The 90 second and 10 second panels work out fine, but I get this error when I am running the 3 second panels. Each panel is ImageSolved, registered in MosaicByCoordinates and trimmed, but PMM throws this error message. Not sure what to do. I was running 1.8.8-9; just updated to 8-12 and all the updates and same error. I will start all over again but in the meanwhile, does this give any clue as to what the problem is?
View attachment 13445
This error was first reported in December 2021, on MAC 0S, with 16 GB RAM:

It is failing in the PixInsight SurfaceSpline process. @Juan Conejero suspects that this is a MAC OS Clang compiler bug. The problem has been reproduced on 8 GB and 16 GB systems, but so far has worked OK on systems with more memory.

I suggested a work around here:

Hope this helps
John Murphy
 
Back
Top