Red Channel in Star Cores Set to 0 during Drizzle

dhb2206

Well-known member
Aug 17, 2018
58
0
I have an instance where many star cores have the red values wiped after drizzling. The same stars in the integration have high red values (>0.9) but I would not expect the values to be wholly removed / rejected during drizzle.

I managed a repair using a rather crass script to reset the Reds to 0.9:

JavaScript:
function main()
{
   // Get access to the currently active image window.
   var window = ImageWindow.activeWindow;

   // is there an active window
   if ( window.isNull )
      throw Error( "There is no active image window!" );

   // Get access to its main view, so we can pick some properties of the image
   // it encapsulates.
   var view = window.mainView;
   var myImage = view.image;
   if (!myImage.isColor)
      throw Error( "Needs to be a colour image!" );
   //stick the view in a changeable mode
   view.beginProcess()
   //iterate the array
   for (var x=1; x<myImage.width-1; x++){
      //iterate along the y-axis
      for (var y=1; y<myImage.height-1; y++){
         if (myImage.sample(x, y, 0) < 0.01)
         {
            //set the value
            myImage.setSample(0.9, x, y, 0);
         };
      };
   };
   //stop changing the view
   view.endProcess();
}

main();
 

Juan Conejero

PTeam Member
Sep 2, 2004
7,548
94
56
Valencia, Spain
pixinsight.com
I cannot reproduce this problem. I need the data set where you are observing this (the calibrated raw frames, in order to perform a drizzle integration), as well as the exact image registration, integration, and drizzle integration parameters you have used. Otherwise I am unable to reproduce and hence understand what happens.
 

dhb2206

Well-known member
Aug 17, 2018
58
0
Juan,

I've put the files in a grabbable location. I got the same problem with a run on M31 last night - not the best of runs, this was a first bash at Andromeda with new kit so rotation is woeful as was tracking with so many cloudy interludes. As usual this is rather a large set of data. In the zip are the calibrated frames (from ASI071 MC Pro in FITS format originally). Debayer run on defaults. Registration was run with frame 22 of 45 as reference and utilised default parameters. Integration was again default with just pixel rejection 1 set to ESD. Drizzle was defaults all the way with CFA enabled (CFA wasn't enabled in the case when I first noticed the problem a few days ago so it isn't that).

Integrated image is fine and dandy, but the drizzled image loses the reds - have a look at the star around (1315, 4755) in the drizzled image and you should see the problem (and hopefully it recreates for you). This should be the same star as at (656, 2378) in the integrated image - here the largest red value I see is about 0.81 but it looks like anything above a red mark of 0.77 has been obliterated during drizzle.

The zip file can be found here, it'll be a pretty slow download as my upload speed isn't enormous: http://dhbpcl.ddns.net/pidata

Thanks,

David
 

dhb2206

Well-known member
Aug 17, 2018
58
0
Update......

I just ran a subset (to see if I could reduce your download time) of the last 15 frames. No problems with the drizzle when I integrate with Winsorised Sigma Clipping, nor with ESD so I think the problem is with my early frames (probably still a bit on the not dark enough side).

Cheers,

David
 

dhb2206

Well-known member
Aug 17, 2018
58
0
Further update - ran again with last 34 frames - again no problem, so it looks like the early frames are the real cause.