NormalizeScaleGradient: Bookmark website now!

Status
Not open for further replies.
... the photometry graph is the diagonal you expect but there are no outliers/spread from the diagonal. Not sure what this is telling me about the star selection within NSG + my frames. I guess that means that the frames are good / star selection choices available are good quality?
If the photometry graph has no scatter, and the gradient graph is perfectly horizontal (no scatter), this means that the reference and target image you are comparing are identical. Somehow you have duplicated some of the images. Try selecting a different target image - you should then see the graphs you were expecting.

I did complete the process through image integration for the OSC image and compared it to the integrated image for the same mosaic pane created by WBPP. I was surprised that there was more visible gradient across the frame from the NSG image than the WBPP integration as I was not expecting that result.
NSG is not designed to remove the gradient. Instead, it removes the relative gradient between the chosen reference and the target images. The integrated image's gradient should be very similar to the gradient in the reference frame. If you wish to minimize the gradient, you need to use the image with the least gradient as the reference.

The main advantage of using NSG is to improve ImageIntegration's data rejection, and to determine more accurate (brightness) scale and image weights. Note that all normalized image will have approximately the same gradient as the selected reference frame.
 
If using a narrow band filter with an OSC camera, some of the color channels may end up having little or no data. For example, a Ha filter would result in no data in the green and blue channel. This could cause NSG trouble, so in these cases it is necessary to split the RGB image into separate channels. If a filter is used that does not create dead channels, NSG can then process the RGB image.
OK, I think I understand. However, when I think of a NB filter for an OSC camera, I'm thinking more along the lines of my Optolong L'Extreme or the equivalent from other providers. It does not result (so far at least) in an image with zero or little data on a particular channel although some targets do slant heavily to the Ha end. In the frames I was testing with, (Eastern Veil nebula), the ZWO ASI2600MC-P w/L'Extreme resulted in good images on all channels, although the B has a higher noise level.
 
If the photometry graph has no scatter, and the gradient graph is perfectly horizontal (no scatter), this means that the reference and target image you are comparing are identical. Somehow you have duplicated some of the images. Try selecting a different target image - you should then see the graphs you were expecting.
Ahhh, the light slowly dawns... ;-)

When NSG popped up the dialog box asking for a target selection, I just assumed it was asking about the target image I had selected for reference. So, I've now 'corrected' that and have checked photometry slope (looks like the demo image) but specifically checking the gradient slope for two frames - one I know was 'selected' in the NSG ImageIntegration (Capture.jpg) and one that I'm fairly certain was excluded from the NSG ImageIntegration (Capture2.jpg) I'm running NSG to Integration again just to make sure I'm correct on this. I do notice significantly different looking gradient slopes between the two frames.
Capture.JPG


Capture2:
Capture_2.JPG
 
NormalizeScaleGradient 1.4.3

Improvements / bugfixes:
  • The console summary text is now sorted by filename or weight
  • Input image formats are no longer restricted to only .xisf and fits
  • Fixes a possible integer overflow error if the input images are in integer format. The images are now converted to floating point.
  • The ImageIntegration ESD auto settings now uses the default ESD settings (outlier fraction = 0.3). The previous settings were preventing ImageIntegration from rejecting the bloated edges from stars with poor FWHM.
 

Attachments

  • NormalizeScaleGradient.zip
    105.2 KB · Views: 138
Last edited:
Hi John,

This is fairly minor. When an NSG configuration is saved as a process icon, and then loaded into the script, the list of target files is not parsed correctly if there is a comma somewhere in the files' path. NSG splits each file path into two incomplete paths at the spot where the comma is. I don't know if there's a way to use delimiters to fix this, or maybe use a list of target files rather than stuffing them into one parameter? Or, maybe this is just a limitation of scripting?

John
 
Hi John,

This is fairly minor. When an NSG configuration is saved as a process icon, and then loaded into the script, the list of target files is not parsed correctly if there is a comma somewhere in the files' path. NSG splits each file path into two incomplete paths at the spot where the comma is. I don't know if there's a way to use delimiters to fix this, or maybe use a list of target files rather than stuffing them into one parameter? Or, maybe this is just a limitation of scripting?

John
I need to concentrate on progressing the C++ version so, at least for now, you will need to avoid commas in filenames / paths.
Regards, John
 
NSG is not currently compatible with drizzle. To make it compatible,
NSG needs to output .xnml files. This is not easily done from JavaScript.
Hence, this functionality will have to wait until I have ported NSG to C++.
That needs doing anyway for performance reasons.
Hello
Great script!!
But it's really a pitty, that it doesn't tolerate drizzle at the time beeing.
I'm just working on a 12 plate mosaic, and my hope was, that NSG could egalize the normalization of the plates, in conjunction with dnaLinearFit and PCC.
Looking forward for the next release.

Best regards
Roland
 
Great script!!
Thanks! :)
I'm just working on a 12 plate mosaic, and my hope was, that NSG could egalize the normalization of the plates, in conjunction with dnaLinearFit and PCC.
Looking forward for the next release.
This highlights a useful point - don't use both NSG and dnaLinearFit.
  • If you use dnaLinearFit and then NSG, you will get the same result as if you only used NSG. Using both will not improve the end result, and does not add value.
  • If you use NSG and then dnaLinearFit, dnaLinearFit will undo some of the corrections that NSG applied. Not recommended.
Are you using PhotometricMosaic to create the mosaic? If you are, the PhotometricMosaic script will apply scale and offset/gradient corrections to the tiles. These corrections use the same strategy as NSG, so again, using dnaLinearFit first will not add value.

Note that PhotometricMosaic is compatible with drizzle because it uses stacked tiles, and does not care if these stacks used drizzle or not.

Regards, John Murphy
 
Last edited:
See this post for more information:

Hi John (and those who need drizzle),

The method in the previous post does not work for me. My calibrated subs contain images taken before and after the meridian flip. So just enlarge the photometric star search area without registering them first does not work.

My getting around is to first register the images, run NSG, and then register again in order to generate the drizzle files. Because the NSGed images are already registered, the second registration should not alter the image content, in principle. However, in reality, there is a small possibility that the second registration further shifts the pixels around by small amounts and introduces a second interpolation between the pixels. This is not desirable. Any additional pixel interpolation would introduce unwanted blurring of the pixels. To avoid this, in the second registration, I select nearest neighborhood for pixel interpolation method. This way, the pixel values will remain unchanged, even if the second registration process thinks that some images need some sub-pixel shift.

That's how I do this at the moment. This takes an extra step and some extra time, but it seems to work.

Cheers,
Wei-Hao
 
Hi John (and those who need drizzle),
The method in the previous post does not work for me. My calibrated subs contain images taken before and after the meridian flip. So just enlarge the photometric star search area without registering them first does not work.

My getting around is to first register the images, run NSG, and then register again in order to generate the drizzle files. Because the NSGed images are already registered, the second registration should not alter the image content, in principle. However, in reality, there is a small possibility that the second registration further shifts the pixels around by small amounts and introduces a second interpolation between the pixels. This is not desirable. Any additional pixel interpolation would introduce unwanted blurring of the pixels. To avoid this, in the second registration, I select nearest neighborhood for pixel interpolation method. This way, the pixel values will remain unchanged, even if the second registration process thinks that some images need some sub-pixel shift.

That's how I do this at the moment. This takes an extra step and some extra time, but it seems to work.

Cheers,
Wei-Hao
It is, unfortunately, a tricky problem to solve. For drizzle to deliver on its promise of extracting extra resolution from the input image alignment differences, it must work on unregistered images. If it is given registered images, that extra information has already been destroyed. It may look as if drizzle has been beneficial, but this is only because of the image resize that it has performed. You would get the same result by using the PixInsight process 'Resample' to upscale the images before registration.

For NSG and drizzle to work, you need to follow my instructions to the letter. In particular:
  • If there is a meridian flip, use 'FastRotation' to rotate the images by 180 degrees either before or after the flip.
  • Run NSG on the unregistered files. To make this work, increase the 'Photometry Star Search' -> 'Star search radius' to its maximum (20).
If the meridian flip produced a pointing error larger than 20 pixels, you would need to divide the data into pre and post meridian flip, and process the data separately. This is probably a better option than using 'FastRotation' anyway. When combining the two stacks, register them and use NSG to determine the stack weights, and then add each stack to ImageIntegration twice (this is a necessary work around: see post https://pixinsight.com/forum/index....ion-to-work-with-only-2-stacked-images.17220/) with data rejection OFF.

Sorry for the bad news. Drizzle is a subtle beast that is not easily tamed...
Regards, John Murphy
 
Last edited:
Simple: When you open NSG script, you remove "nsg" in Postfix. Is over. You can use Drizzle data from Registration with NSG data
kolec
 
One of the things that I have observed over time is that altitude as a measure of how "good" a frame is, usually works if you have only data from the same night. With multi night, in general was is affecting the most the quality in my view is the presence and illumination of the moon. I wanted to ask how moon illumination impacts the measurements in the script. For example, would a full moon result in frames with higher measurements ?

Thank you
 
One of the things that I have observed over time is that altitude as a measure of how "good" a frame is, usually works if you have only data from the same night. With multi night, in general was is affecting the most the quality in my view is the presence and illumination of the moon. I wanted to ask how moon illumination impacts the measurements in the script. For example, would a full moon result in frames with higher measurements ?

Thank you
The best way to choose the reference frame is to blink through the images. Choose the image with the least complex gradient. If the gradient is the same in all images, you can choose any reference frame. In this case it does not matter because the weight measurement is relative. For example, if you chose a poor reference frame, that frame will be given a weight of 100%, but many of the target frames will then exceed 100%. Everything will still work out as it is supposed to.

The altitude column was added as an extra guide, but blinking the images is better.

Background illumination (light pollution, moonlight, twilight, or imaging through high clouds) will increase the noise in the image. NSG will reduce the weight of these images accordingly.

Hope this Helps, John Murphy
 
Hi John. Many thanks for developing this script. I have spent many hours revisiting old images and finding NSG improves the final image. Wonderful!

I don't want to distract you from porting this script to C++ but wondered if it were possible to allow manual override of both Focal length and Pixel size when setting the reference frame in NSG?

I am running into issues with DSLR CR2 files from a Canon 1100D. FOCALLEN exists in the CR2 file (and subsequent calibrated files) but is the incorrect value. XPIXSZ is absent throughout.

After calibration/registration, setting the reference frame in NSG prompts for Manual Entry. However, only the pixel size is editable (and correct) but the focal length is greyed out.

I hope there is a simple solution.

Cheers

John
 
Hi John. Many thanks for developing this script. I have spent many hours revisiting old images and finding NSG improves the final image. Wonderful!
Pleased to hear it! :)

... wondered if it were possible to allow manual override of both Focal length and Pixel size when setting the reference frame in NSG?
I will see what I can do ...
I am currently finishing a major update of my PhotometricMosaic script. It is now faster, easier to use and more accurate. Once this is finished, I intend to update NormalizeScaleGradient with one of the PMM improvements. I should be able to add your request then.

I am also thinking about adding an optional 'fast' mode to NSG. This would reduce the number of stars it used to determine the scale (but still enough to be accurate) and speed up the gradient correction by only correcting the dominant gradient. This would normally be sufficient for narrow band images, and may also often be sufficient for wide band if the field of view is less than 1 degree. Would anyone find this useful?

Regards, John Murphy
 
Thanks for you speedy response. Really appreciate all you are doing.
I am also thinking about adding an optional 'fast' mode to NSG... Would anyone find this useful?
Indeed, this would be useful.(y)

Cheers

John
 
I am running into issues with DSLR CR2 files from a Canon 1100D. FOCALLEN exists in the CR2 file (and subsequent calibrated files) but is the incorrect value. XPIXSZ is absent throughout.

After calibration/registration, setting the reference frame in NSG prompts for Manual Entry. However, only the pixel size is editable (and correct) but the focal length is greyed out.

I hope there is a simple solution.
In 'Raw Format Peferences' (Format Explorer, double click on 'RAW') you can enable 'Force focal length' and input the correct value.

Bernd
 
Status
Not open for further replies.
Back
Top