Author Topic: Image Integration - Zero or insignificant signal, when there is TONS of signal  (Read 5242 times)

Offline LX200

  • Newcomer
  • Posts: 18
Took the following pics

1. 6 x 5 minutes of Ha, OIII and SII
2. 20 bias
3. 12 x 5 min darks

Calibration worked fine
Registration worked fine

Now, I go to Integrate the 6 calibrated and registered Ha images

Immediately upon try to do this, I get the error on the first image

C:/Users/AstroPC/Documents/AstroPics/Testing Testing/Autosave Image -0001DB300HA_c_r.xisf
Loading image: w=3326 h=2504 n=1 Gray Float32
Computing image statistics: done
79 FITS keyword(s) extracted.
79 FITS keyword(s) extracted.
*** Error: C:/Users/AstroPC/Documents/AstroPics/Testing Testing/Autosave Image -0001DB300HA_c_r.xisf: Zero or insignificant signal detected (empty image?)
<* failed *>

THE IMAGE IS NOT ZERO OR INSIGNIFICANT !!!!!!!!!!!!!!!!  IT HAS HUGE AMOUNTS OF SIGNAL.  Sorry for yelling.. HOURS OF FRUSTRATIION TRYING MANLY DIFFERENT THINGS

I have tried turning off the file cache, turning it on. 

Any ideas?  Where to start?  I use the demo program to do a successful LRGB, then bought the software.  This is the first processing attempt, and I am completely stumped and no idea where to turn.  THERE IS SIGNAL THERE.  Why does PixInsight say zero.  ARGGGHHHHHH.

I HAVE ATTACHED a screenshot showing the error, and the stretched file with image stats... this is the one PixInsight says has no signal.

Offline pfile

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 4729
calibration probably did not go fine, the image looks badly clipped...

rob

Offline LX200

  • Newcomer
  • Posts: 18
OK... I took your advice on the clipping, and yes, it is very clipped.... I guess I did something dumb... but there was a reason I did....

So... I had six images, call them img1 thru img6.

First I calibrated.

Next, I went to do registration.... I picked img1 as the reference, then told it to "register"  img1 thru img6.... so I am saying img1 is the reference, and also using img1 as the first calibrated image.

Now why do this?  Well, shouldn't my reference image be one of the images from by group?  Now, I thought registering img1 with img1 as the reference was dumb, but, the process produces new files with _r attached, so I want _r attached to "img1_c", which is my reference image....

Well, if I do this, img1 looks super clipped, and gives the above error... All other images that get registered, i.e. img2 thru img6, look OK, NOT heavily clipped.

SO, am I doing this wrong?  Why did registering img1 with img1 as reference look so weird ???

Offline pfile

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 4729
hmm, what you are describing sounds fine (maybe - not entirely sure what you mean).

after calibration you should have img1_c ... img6_c

then you choose img1_c as the registration reference and register img1_c ... img6_c to yield img1_c_r ... img6_c_r

then integrate img1_c_r ... img6_c_r

you can choose img1 as the registration reference instead of img1_c, assuming the uncalibrated images are clean enough for StarAlignment to grab all the stars.

you don't strictly have to run img1_c thru StarAlignment because img1_c and img1_c_r should be exactly the same file... but it doesn't hurt.

perhaps img1_c is just messed up for some other reason (cooler temperature not stable during img1, so dark signal is different than darks, or maybe img1 taken with different gain or iso setting from the darks, etc.) its worth checking img1_c to see what it looks like relative to the other frames.

rob

Offline LX200

  • Newcomer
  • Posts: 18
You've hit my massive confusion right on the head....

If I register img1_c, with img1_c as the reference, I expect img1_c to get a 0px by 0px by 0 degrees rotation to register... so I expect img1_c_r to be an exact duplicate of img1_c.

No.  It is a heavily clipped output showing brighter stars, jet black background and a bright featureless nebula in the center.

Why is registration changing an image so much?  I thought registration just shifted stuff around, with little change to the data... i.e. just move the data around, don't clip it.  Weird.

And again, registration with img1_c as reference does register img2_c, img3_c, img4_c, Img5_c and Img6_c correctly.  And all those images are virtually identical to img1_c.

Totally confused.

In the end, I can integrate   img1_c along with img2_c_r, img3_c_r.....img6_c_r....

Offline pfile

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 4729
i don't see why img1_c should be changed at all during registration to img1_c_r. if you just register that single image, it will be easier to read what's in the console output. it should show a "null" transformation matrix. is that what you see?

rob

Offline LX200

  • Newcomer
  • Posts: 18
I think I figured it all out....

I am new to narrow band imaging.  At the end of a long night at a very dark site, I tried 300 second exposures of  M27....

If I look at my resulting narrow band picture, and do stats on the picture, my average pixel is at like 275... there is bright nebula, but not much else on the shot.

If I look at my 300 second darks, they have avg pixel at like 265.  So when I calibrate, I produce incredibly clipped images... and these just don't register or integrate correctly.

I guess I have to bin or take much longer exposures with narrow band.... learning....

Offline pfile

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 4729
ah, ok. yeah, i regularly do 1800s narrowband exposures with 5nm filters...

rob

Offline LX200

  • Newcomer
  • Posts: 18
Well, that cinches it.  I win PixInsight dumbo user of the week award.  I subtracted both bias and dark from my lights.  That was enough to kill all the signal except the dumbbell itself and a few stars.

Derp.

But that leaves a question.... if you specify bias and dark to BPP, what does it do with bias?  Only remove from flats?

Offline pfile

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 4729
i think all BPP ever uses a bias frame for is to subtract from the dark in case you want to use dark optimization.

in your case if you specified a dark and a bias to ImageCalibration and did not tick "calibrate" in the dark area, then yeah, the bias will be subtracted twice (since it's present in the bias master and the dark master). if you tick calibrate, then IC will do:

light - bias - ((dark - bias)*scaling_factor)

so the bias will not be subtracted twice.

rob

Offline chris.bailey

  • PixInsight Addict
  • ***
  • Posts: 235
It can help to do things long hand sometimes as you can inspect and sense check the output images at each stage. I find that different sensors retire slightly different workflows. So

Process>Preprocessing>Calibration - sense check overall values and that flats have worked
(Process>Preprocessing>Cosmetic Correction) - Optional but handy when you scale darks to get rid of errant pixels or in fact don't use darks at all. Also handy if you have column defects.
Process>Preprocessing>Star Alignment - watch for artefacts around stars and reduce clamping threshold if necessary
Process>Preprocessing>Image Integration - try different rejection algorithms and rejection criteria

You can also put the Script>BatchProcessing>SubFrameSelector script in the mix somewhere to add a more scientific factor to selection. I tend to use it after calibration and cosmetic correction.

It sounds a bit long winded but, when you have done it a few times, it does not take much longer than it does to load all the frames up in BPP.