PhotometricMosiac 4.0

Hello Pixers,
I am having a problem with the Photometric Mosaic script with an M31 data set. This was shot with 60% overlap. When I run the script and trim the tiles the previews show the proper 60% overlap. But, when running the script the overlap region is switched to horizontal instead of vertical and the resulting offset image is created. Is there a way to change the overlap from horuzontalcto vertical? Other mosaics I have run with only 20% overlap do not do this.
 

Attachments

  • BadB_Mosaic.jpg
    BadB_Mosaic.jpg
    189 KB · Views: 89
Hi there stevanhay this is exactly what I experienced earlier:

If you have so much overlap that the aspect ratio is close to being square the software might make the wrong choice as to whether it's a horizontal or vertical stitch....I ended up erasing the excessive overlap and than it worked first try.....
 
Hi there stevanhay this is exactly what I experienced earlier:

If you have so much overlap that the aspect ratio is close to being square the software might make the wrong choice as to whether it's a horizontal or vertical stitch....I ended up erasing the excessive overlap and than it worked first try.....
Thanks! I didn't expect such a quick reply and ended up hammering it out with four mosaics with the two sub-frames. I think this correct approach might yield a better result. I will try it. Tonight I'm decreasing the overlap on my N.I.N.A. mosaic to avoid the extra hassle.
 
Sounds good. I did suggest to John that perhaps there's a 'Force Vertical' or 'Force Horizontal' user override, I tend to go overkill on my panels also because coma gets so bad on wide field DSLR lenses.....
 
Dear John,

Your script is great and produces really seamless mosaics.

I have a question. Recently I captured the Hearth and Soul region with a 2x2 mosaic. I joined the frames without any problem.

However I have two separate frames for the Hearth and for the Soul region from last year. I want to add the signal from those frames to my new mosaic. However the regions are overlapping the script allows only for replace of region.

Is there a plan to allow the photometric mosaic script to work with overlapping regions so that the SNR of those regions to be averaged out and improved?

Thank you once again!

Kind regards,
Ivan
 
Do you see any issue with skipping the TrimMosaicTile step if you use the AutoCrop feature in the latest WPBB? I just tried it and it looks ok to me, but I wanted to check if I might me getting better results using TrimMosaicTile. Perhaps MosaicByCoordinates causes edge issue when it warps the frames to match.

If it's ok to skip TrimMosaicTile, then would it be possible to have PhotometricMosaic to recognize if you used AutoCrop and not display the warning in that case? It could be an option to be selected. I don't know if AutoCrop leaves some recognizable FITS header to make that easy. You could key off the autocrop keyword in the filename.
 
Do you see any issue with skipping the TrimMosaicTile step if you use the AutoCrop feature in the latest WPBB? I just tried it and it looks ok to me, but I wanted to check if I might me getting better results using TrimMosaicTile. Perhaps MosaicByCoordinates causes edge issue when it warps the frames to match.

If it's ok to skip TrimMosaicTile, then would it be possible to have PhotometricMosaic to recognize if you used AutoCrop and not display the warning in that case? It could be an option to be selected. I don't know if AutoCrop leaves some recognizable FITS header to make that easy. You could key off the autocrop keyword in the filename.
From the PhotometricMosaic help (section 1.2 Prerequisites):
TrimMosaicTile
Use the script 'Mosaic -> TrimMosaicTile' to remove soft or reduced brightness edges. Even if your mosaic tiles had clean edges (for example, the stacked images were cropped before using ImageSolver and MosaicByCoordinates), the registration process creates a slightly soft edge. The images will require a few pixels to be eroded from them. Do not skip this step - it is vitally important for a seamless result.

So the answer is that you do still need to use TrimMosaicTile, because the registration performed by MosaicByCoordinates will produce slightly soft edges, and these need to be removed.

Regards, John Murphy
 
John: your work with PMM continues to amaze me. So much to my surprise, in my latest use, I had a nasty surprise with gradients in the bottom third of a three panel mosaic. As always, I was using default settings. The result sent me into the documentation and I was then able to produce a much better result, adjusting sample rejections and gradients. However, there is still an issue around the haloing of the star along the lower left edge in the lowest panel. I don't see an answer to this, other than it is likely traceable to less than pristine subframes, as there was some high cloud that probably contributed to the halo in the first place. I am wondering if performing gradient reduction to the individual panels prior to engaging the PMM process would work in these cases? Of course I could just go ahead and try it and see, but thought I would see if you had any thoughts about this or how to deal with these kind of problems in general.

Attached are before-and-after images; before: at defaults and after: after adjusting sample rejections and gradients.

Thanks again for your work on this script suite and any insights into this problem.

Norm
defaults.jpg
afteradjustments.jpg
 
I now have a bit more time, and can take a look if you still need it. You would need to provide a link the the two registered images that are causing you trouble.
Regards, John Murphy
 
The most common mistake is a non black area surrounding the registered images. This can happen after applying DBE. You will need to apply PixelMath to remove this.
Sorry, I am a newbie. I am experiencing the same problem as @jpeirce . I don't know how to do this PixelMath thing. Can anyone help me?
 
Sorry, I am a newbie. I am experiencing the same problem as @jpeirce . I don't know how to do this PixelMath thing. Can anyone help me?
The PhotometricMosaic reference documentation describes how to do this:

Black Background
Make sure that the black background around each image is actually black (zero). If your join fails at its ends, it is often due to very small non zero values (for example 0.0002). Correct with PixelMath - for example 'iif($T < 0.0003, 0, $T)'. Almost black regions are introduced by post processing after MosaicByCoordinates.

If you don't do any post processing after MosaicByCoordinates, you will not have any 'almost black' regions to remove.

Hope this helps,
John Murphy
 
The PhotometricMosaic reference documentation describes how to do this:

Black Background
Make sure that the black background around each image is actually black (zero). If your join fails at its ends, it is often due to very small non zero values (for example 0.0002). Correct with PixelMath - for example 'iif($T < 0.0003, 0, $T)'. Almost black regions are introduced by post processing after MosaicByCoordinates.

If you don't do any post processing after MosaicByCoordinates, you will not have any 'almost black' regions to remove.

Hope this helps,
John Murphy
Thank you very much John.
 
Hi. I´m just getting started with PhotometricMosaic (having given up on GradientMergeMosaic), but I´m stopped by the error message below. Any ideas?

Best regards,
Sigurd
 

Attachments

  • Skjermbilde 2023-09-30 kl. 14.09.56.png
    Skjermbilde 2023-09-30 kl. 14.09.56.png
    582.9 KB · Views: 41
Hi. I´m just getting started with PhotometricMosaic (having given up on GradientMergeMosaic), but I´m stopped by the error message below. Any ideas?

Best regards,
Sigurd
I am guessing that you are using Mac OS with 16 GB of memory or less. Under these conditions, the PixInsight C++ SurfaceSpline function can fail.

@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.

The work around is described here:


Regards, John Murphy
 
The latest version of PhotometricMosaic (version 4.0) can now be downloaded from my website:


This release includes some important bug fixes, more accurate graphs and many controls now have their own reset button.

It also contains a new section: Join Orientation.
Previously, if you have a very large overlap, PMM would fail. This was because the calculated join orientation assumed that the join line is longer than the overlap thickness. You can usually leave Join Orientation on its default setting (Auto). However, if you have a very large overlap, you are now able to specify the join orientation.

TrimMosaicTile now defaults the trim size to 5 pixels.

Regards, John Murphy
 
I am guessing that you are using Mac OS with 16 GB of memory or less. Under these conditions, the PixInsight C++ SurfaceSpline function can fail.

@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.

The work around is described here:


Regards, John Murphy
That worked, many thanks!
 
I´ve just produced my first mosaic, but strange things happen to one of the joined panes. See below (original right bottom pane included for reference). Any settings that will fix this? Did it one column at a time.

Skjermbilde 2023-09-30 kl. 16.33.12.png
 
I´ve just produced my first mosaic, but strange things happen to one of the joined panes. See below (original right bottom pane included for reference). Any settings that will fix this? Did it one column at a time.

View attachment 20168
You need to first create two columns, then join the two columns to finish the mosaic. This strategy avoids the awkward "corner tile" join.

This strategy is needed because PMM is designed to join only one side at a time. Hence you cannot add a corner tile to an L shaped mosaic.

Regards, John
 
Yes, I did that. The strangeness appeared on that first join (like a black and white image with way too much contrast), and then it got worse when I joined the two columns togheter.
 
Back
Top