Local Normalization FixZero error

[gamempire]

Hi everyone,

First post, so please bear with me as I'm stilling learning Pixinsight (and apologies if I've posted this in the wrong area).

I've been using the Light Vortex Astronomy tutorials to process my images, and have been pretty successful so far (http://www.lightvortexastronomy.com/tutorial-pre-processing-calibrating-and-stacking-images-in-pixinsight.html). However, I was processing some OIII data for NGC 281 that I captured from iTelescope, and I got a weird error while running the local normalization process that I can't seem to find any information on. Googling only returns the error message in the GitHub repository. Whats strange is that my narrowband data for Ha and SII ran through the Local Normalization process fine. Per the tutorial, I was running local normalization after running the star alignment function.

*** Error: LocalNormalizationThread::FixZero(): Insufficient data to sample background image pixels, channel 0

Here is a dropbox link with some of the data if someone would be kind enough to take a look (theres a zip archive in there to make downloading it easier): https://www.dropbox.com/sh/vmqlqgan0xxo101/AAD5lrtCjlKBh4ihM7yQmve3a?dl=0

Also, as a general question for Local Normalization, should each filter be normalized against the best/brightest image overall, or just the best/brightest image for that filter?

Thanks much!

[pfile]

if you are just starting out, my recommendation is to not do LocalNormalization. it is a very tricky tool which i would characterize for advanced users, and is really not necessary in most cases. i really wish kayron had not put that in his tutorial flow as debugging problems with LN is really not something beginners should be saddled with.

also iTelescope can be a hard place to start. i believe they provide calibration files generated with Maxim. 99% of the time these are incompatible with PI (this is not a PI problem, rather, you really can't use calibration masters generated in one program with another program due to FITS files incompatibilities.)

the "zero signal" problem to me indicates bad calibration.

if iTelescope provides pre-calibrated lights, i would just use those, and skip the LN for now.

rob

[gamempire]

I'm using precalibrated lights, so I'm unsure as to why the Ha and SII data is fine and the OIII isn't.

And while I'm no stranger to astrophotography, the reason I've been using iTelescope is because I can't setup my 9.25" SCT anymore after 2 shoulder surgeries, and don't have a location to build a permanent structure for it at this time. iTelescope allows me to continue my DSO astrophotography until I'm able to do so

Thanks for the tip about their calibration files being incompatible with PixInsight. I used to use Maxim to control my own setup, but switched to PixInsight for processing since its Mac and Windows compatible and I'm on the road a lot with my mac laptop. When running through the tutorials originally, I wanted to learn how to do all the preprocessing, and couldn't figure out why I was getting poor results with the master darks/flats/bias files provided by iTelescope, so I just decided to stick with the pre-calibrated files in my workflow.

But I'll skip LN for the foreseeable future. Coincidentally, I couldn't figure out why I was getting blotchy spots using DBE on another target I was working on, and ran across a post this morning on the forum that explained it was due to Local Normalization.

[pfile]

OK, thanks for the context. it helps if you have some prior experience when starting to use PI.

can you post just a couple of the OIII frames? i suppose it could be that the signal is just really weak; would not be the first time that an OIII frame looked like that. or, maybe iTelescope's calibration is bad.

you can try increasing the scale in LN to try to get rid of the blotchiness, but you probably saw that in the other thread.

rob

[gamempire]

Here's a dropbox link to some of the OIII frames: https://www.dropbox.com/sh/vmqlqgan0xxo101/AAD5lrtCjlKBh4ihM7yQmve3a?dl=0

My NGC281 project has been a total mess it seems due to darks and flats being bad and needing a bunch of recalibration. I did a quick HST color combination using PixelMath and got a horrible gradient. Might just scrap the data I have and start over

[pfile]

ok i looked at one of the o3 frames.

i think despite T05 being a pretty fast telescope, 120s exposures for OIII are just too short. there's not a lot of OIII and SII signal out there (with of course a few notable exceptions)...

these are calibrated f32 images, so representing them in ADU counts is not 100% meaningful, but it's hard to get a handle on the floating point numbers. i measured a mean of 118 ADU in the nebula and 107 ADU in the background... so there's only 10ADU worth of signal there. that may account for LN not really being able to discern what the background is vs. signal. hard to know without the original frames if you've overcome the read noise @ 120s but i suspect not.

rob

[oldwexi]

Hi gamempire!
i have checked your OIII images.
After stacking they have absolutely NO gradient!
These are excellent images. You need only more of them and maybe with longer exposure.

If you talk about a gradient that must be in the Ha images ?
You have to remove the gradient in the Ha before you mix them with OIII.
The gradient in your color image is not a mess its a normal and nice one.
DBE gets it away very good.

Since 2014 I am doing a lot and all of my imaging with iTelescope and my experience is:
take the calibrated images from them they are usually ok.
Self calibration with Maxim Masters leads to troubles where you need to have a lot of experience to solve them!

Here a link to my results of using iTelescope:
http://www.werbeagentur.org/oldwexi/gallery.html
All the OIII image there are with 5 minutes exposure. And in minimim more than 40 exposures!

So as mentioned 6 x 2 minutes OIII is not enough despite that the result you got in OIII is excellent for these
minimum exposures.

Gerald

[gamempire]

Thanks to both of you for the advice. I actually have 23 OIII frames at 120s per frame (I had to discard  9 of the original 32).  I only put a few frames in so someone could maybe check them to see if there was an issue that I was missing, perhaps in the fits header data. I just put all the OIII frames in that dropbox folder if you don't mind taking a look again Oldwexi.

Also, can I use DBE without doing a local normalization?

I've gotten some pretty great results with the other telescopes, it was just T5 was giving me a number of issues with tracking anything over 120s, and the flats were old which caused the NGC 281 data to not be so great. Everything else in terms of precalibrated images from the other telescopes has been great, and Pete over at iTelescope was happy to try and recalibrate the data I had from T5 after he redid the flats.

I attached a shot of M16 I did in August and September using T30, and while its not sharp enough to print (I'm going to work on learning how to mask nebula next month to be able to sharpen dust lanes and such), I'm still very happy sharing it. It was the first image that I processed almost completely in pixinsight (there was some clone stamping done in photoshop to clean up some hot pixels, which was easier than using the clone stamp tool in Pixinsight).

[pfile]

well 120s might be OK, it's really a question of if the read noise has been swamped by this exposure length. you'll probably never swamp the read noise in the background of a narrowband image from a dark site, so the question is more about the target itself.

you can absolutely do DBE without LocalNormalization. regular old "full-frame" normalization is part of the ImageIntegration module and happens behind the scenes. the purpose is to make all the input images in the integration statistically compatible with one another so that pixel rejection can be done properly. if you imagine a frame with a high background level and one with a low background level, the only way to know what pixels are actually outliers is to first multiply the brighter image by some scaling factor < 1.0 so that the two images have similar levels. that's what normalization does. under normal circumstances, if you set up the pixel rejection correctly there should be no reason to have to paint out hot pixels...

i think the M16 image looks great, though i wonder if there is some black clipping going on - there should be a lot more signal in the area of the "loop" of the eagle's head.

rob

[gamempire]

Again, thank you for the advice rob. I've added it to my notes.

Just one more question (well, two) about Local Normalization if you'd be so kind. I've attached three screenshots of an Ha, SII and OIII integration for m42. The images were autostretched. Local normalization was used (scale was 512), and the reference frame was an Ha image (instead of doing LN for each filter). As you can see, the SII and OIII images are blown out in the center.

Say I have my narrowband images in Ha, SII and OIII. If I were to use Local Normalization in the future, should I use LN with the brightest overall image as the reference image for all the data? Or should I normalize separately for each filter?

Thanks again to everyone for the help and advice. Still wish I could figure out whats wrong with those OIII files.

[pfile]

yes, something is definitely wrong with the SII and OIII images. i can't say if it was due to LN or some other problem without seeing the subexposures.

i think LN is supposed to be used on a per-filter basis, so you'd take the strongest, most gradient free sub as the reference for a particular filter and use that as the reference for the rest. i think when juan introduced the tool there was also talk of perhaps using a master (made without LN) which had undergone careful DBE as the reference for a subsequent run of LN and reintegration of the images.

rob

[msmythers]

rob

You are correct in that was the discussion on the use of LN. The idea is that each filter(for mono camera) would be treated separately and to use the best sub from the captured set or from some other capture. If a good enough sub was not available than the user should use DBE to the best sub(least artificial gradients) and correct that sub for use as the reference. Since each filter bandwidth would present different normal(real to object) gradients in the captured area you could not mix filter references. That's what I remember from those discussions. Technically the reference did not need to be from the capture session but would need to meet the geometry specs.



Mike