GradientMergeMosaic odd results

[gnewell]

I've been using dnaLinearFit and GradientMergeMosaic on a few narrowband projects would good results.

Now I'm trying to add RGB stars and don't understand the results I'm getting. Even though the individual registered frames look the same under screen stretch, when GradientMergeMosaic is applied (average) the upper right hand frame looks very different from the original registered frame and from the other merged frame.

Also I see strange behavior in that making a mosaic from two of the four registered farmes things look correct, but if I do 3 or all 4 things are wonky.

The workflow is stack each frame/filter, ABE, dnaLinearFit, WCS, MosaicFromCoordinates, GradientMergeMosaic. This is PI 1.8.8.3 patched to date.

Any ideas?

Again it's working for me for NarrowBand (although you could convince me that the upper right frame is not completely correct there as well).

 

[gnewell]

Here's the Ha, which seems mostly OK.

[pfile]

if you compute an STF for the first panel, and then apply it to the remaining 3 panels, do the images look correct?

wondering if DNALinearFit failed for some reason and one or more of your panes has the wrong brightness.

rob

[gnewell]

No, they all look the same.

[gnewell]

or rather "yes" to your first question. Yes, they all the the same.

But "no" to thinking dnaLinear fit did something funny.

[pfile]

well i am out of ideas, maybe you can post the 4 frames to drobox or something

rob

[gnewell]

https://drive.google.com/drive/folders/1LzaKvT5VVYG9pXNdz6GjznaDmEDnuW8A?usp=sharing

[pfile]

something is definitely weird here, the linear fit in the LF frames is not good for some reason. even trying to merge 1 and 3 separately from 2 and 4 gives some weird stuff.

2+4 behaves a little better (after you crop it down to just the active area) but the levels across the 2 panes are definitely different after merging.

i don't know if this is down to gradients in the overlapping areas or what. i need to look at it more.

rob

[pfile]

ok, i think i know what's wrong - i looked at the original files and 3 of them have "black" borders which i guess are integration artifacts, probably from subexposures that don't totally align with one another. number 4 has some rattiness at the right side which should also be cropped.

since the borders are not totally black, GMM is picking up on those and trying to merge them. it's throwing off the brightness scaling and making that one whole frame too dark.

i cropped the masters with DynamicCrop and then re-ran ImageSolver and then MosaicByCoordinates and got something much more reasonable. but i didn't run any background extraction so the mosaic is still messed up. regardless i'm pretty confident that the main problem is those non-black black areas in the original panes...

rob

[gnewell]

OK thanks I will look at that, but wouldn't it be unusual to crop pieces of mosaic before joining?

One of the advantages of this particular mosaic workflow is you can get away with little overlap, but it seems to me that cropping the individual pieces may, in some cases, make that overlap even smaller or disappear.

I wonder if replacing the edges with sky brightness would, vs. cropping, help? I'll probably try that as well as cropping.

Oh, GMM AFTER MBC is always going to have black areas, in the "_registered" input files, where the other frames go so?

[pfile]

i'm talking about the integrated masters, before any mosaic registration. theres "garbage" at the edges caused by the raw subs not having the same pointing - it could be due to dithering or it could just be due to pointing errors at the time of acquisition.

at the best those areas are low SNR and at the worst (in your case) it seems that only 1 or 2 frames had any data there, leading to just some useless signal in the margins of the image... so it needs to be cropped anyway.

rob

[gnewell]

OK I'm trying it now but I'm getting a timeout on http://vizier.u-strasbg.fr when I try to plate solve the cropped frames 

I wonder if I can just save as .fit and solve on nova.astremetry.net, for the WCS data.

[gnewell]

It looks like dnaLinearFit wants all views to be exactly the same dimensions. So cropping will have to be the same.

[pfile]

yea i think yesterday people were having problems with the vizier server. i downloaded the PPMX.bin catalog from the PI website a long time ago and just use that.

good point about DNALF wanting all the frames to be the same size, makes sense. i guess you can come up with a crop that is conservative enough for all 4 frames and then apply it to all images?

rob

[gnewell]

Maybe French Labor Unions shut down their power yesterday? I'll have to learn your trick of downloading the database and using it locally.

I did try to use nova.astromety.net but pixinsight complained about fit files not being specific about orientation (which doesn't seem correct from my understanding of fits and WCS, kind of the whole point...) and my results had all the frames flipped. I can show how to detect "parity" from WCS scale factors if anybody cares.

Anyway, yeah, I had done a dynamic crop of each image so took the minimum values from each of those and did "Crop" to those dimensions and choosing the anchor point.

Man, after a lot of work I have a usable result, so thanks again for the tip about cropping. With the cropped images I also had to enter Coordinates for each image and solve separately, vs. before I just had the center of the mosaic for all frames and solved them all at once.

It would be nice to have a blind solver. Maybe that will be my first attempt at PI scripting, since I have done similar (but in python) for the upcoming Stellarium 19.3 and placing your own DSO images in the Stellarium sky.