Author Topic: DrizzleIntegration using the wrong source images?  (Read 686 times)

Offline gamempire

  • Newcomer
  • Posts: 16
DrizzleIntegration using the wrong source images?
« on: 2019 February 11 15:53:43 »
Heya everyone,

I've got a weird problem, and maybe I'm misunderstanding how the DrizzleIntegration process works. Let me set up the scenario.

I have six images for CentaurusA in green, the third image has a satellite trail. All of my images are dithered.

Steps:
1. Cosmetic Correction
2. Star Alignment (registered and drizzle files generated)
3. ImageIntegration
4. Drizzle Integration

I generated a line that is 5 pixels wide using 5-d2seg(15,869,3071,1339) in pixelmath, and applied it as a mask to the third image. It starts at 15 because the image is already registered with star alignment. I then opened the second image, and applied it in Pixelmath to the third image. Satellite trail is gone and replaced with data for the line from the second image, and I'm back to having six good images for my green data.

I then integrate the data using ImageIntegration, and I made sure generate drizzle data is selected to update the drizzle files. I then move on to DrizzleIntegration, and thats where the issue is. When I go to integrate the green data, I'm back to having a satellite trail in the image. I checked the process console, and noticed that it is using the cosmetically corrected files located in a different directory and not the star aligned files for the image. I opened up the xdrz drizzle data file, and saw that the file name ends in _cc, instead of _cc_r. And I'm sure the drizzle files are being updated when I run image integration, as they are the most recently modified files.

Am I misunderstanding the way DrizzleIntegration works and the files it uses? Did I miss a step in updating the drizzle files to use the star aligned images (it doesn't seem so)?

I've attached 3 screenshots of the basic star alignment, image integration and drizzle integration settings I use. If there's any other data (drizzle files or console logs) that might be helpful in solving the problem (if it is indeed a problem), I'd be happy to provide it. If I'm being dense and just missing a simple setting or step, please just point and laugh at me while I bang my head on the desk (but also fill me in what I was missing, please).

Thanks for the help!

-Josh

Quick edit: the reason I'm using the line masking method is because image integration is not rejected the entire satellite trail on my green data, but was completely successful on rejecting it on my luminance data.

Offline pfile

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 4729
Re: DrizzleIntegration using the wrong source images?
« Reply #1 on: 2019 February 11 16:18:37 »
IIRC the drizzle files are basically metadata for the original unregistered files, so i think you'd have to make the change to the unregistered file to get it to be reflected in the drizzled image.

rob

Offline gamempire

  • Newcomer
  • Posts: 16
Re: DrizzleIntegration using the wrong source images?
« Reply #2 on: 2019 February 11 18:51:13 »
https://pixinsight.com/forum/index.php?topic=8342.0

Here's the process I'm using to fix the satellite trail. I can't fix the cosmetically corrected image until the images are registered to each other. I understand that the drizzle data files have the image registration in them so they can use the cosmetically corrected files. Basically, I feel like I'm in a catch 22: I can't fix the satellite trail without registering the images, but when I fix the satellite trail, I can't use DrizzleIntegration for the repaired image.

Offline pfile

  • PTeam Member
  • PixInsight Jedi Grand Master
  • ********
  • Posts: 4729
Re: DrizzleIntegration using the wrong source images?
« Reply #3 on: 2019 February 11 19:34:10 »
well i can think of two ways out of this:

first is that since you only have one image with the satellite, rather than trying to repair it, just overwrite the streak with 1.0 or 0.0 and then it can be very easily rejected by the normal pixel rejection techniques. the SNR under the streak will be a tad lower, but maybe not perceptible.

the other way would be to do exactly what you are doing, but register one of the good images to the bad image to use as source material for the streak. then just throw away the registered one, and start the whole process from there, as though your bad image was clean to begin with.

rob

Offline sharpie78

  • Newcomer
  • Posts: 30
Re: DrizzleIntegration using the wrong source images?
« Reply #4 on: 2019 February 13 03:33:24 »
There is a 3rd way Rob......Don't include the sub with the Star trail.....

Sorry....not helpful but couldn't resist  ;)

Offline sharpie78

  • Newcomer
  • Posts: 30
Re: DrizzleIntegration using the wrong source images?
« Reply #5 on: 2019 February 13 04:30:18 »
Just a thought though......Are you able to remove the trail prior to star alignment ? If you can....surely doing that, then registering all 6 files (including the 3rd image with a corrected satellite trail) would result in a stack without the trail ?

I find it helpful to have a seperate folder of files for each step in calibration. In my registered folder I have the files that have been calibrated/cosmetically corrected/debayered/approved&weighted and registered (ie. targetname_c_cc_d_a_r.xisf), my drizzle files and my local normalization files. When I integrate the files from this folder PI does an excellent job of removing any stray artefacts that may be left over from cosmetic correction. This updates my drizzle files and I then do a drizzle integration.

Once I've got a Master that I'm happy with I go back and delete all my files up to the point before they're registered. This leaves me with one set of calibrated/CC'd/debayered and approved files that I back up onto an HDD to use later if I do another imaging run on that target.

Dunno if that helps but as I said.....just a thought  :)
« Last Edit: 2019 February 13 04:44:39 by sharpie78 »

Offline gamempire

  • Newcomer
  • Posts: 16
Re: DrizzleIntegration using the wrong source images?
« Reply #6 on: 2019 February 13 16:53:46 »
well i can think of two ways out of this:

first is that since you only have one image with the satellite, rather than trying to repair it, just overwrite the streak with 1.0 or 0.0 and then it can be very easily rejected by the normal pixel rejection techniques. the SNR under the streak will be a tad lower, but maybe not perceptible.

the other way would be to do exactly what you are doing, but register one of the good images to the bad image to use as source material for the streak. then just throw away the registered one, and start the whole process from there, as though your bad image was clean to begin with.

rob

The first option will probably be best, I didn't even think of that, so thank you. The second option requires a few more steps to just get one frame of good data, and if I see that the SNR is awful, I'll go with that. In this case, the satellite trail went right through CentaurusA, so keeping the SNR high would be best.

Just a thought though......Are you able to remove the trail prior to star alignment ? If you can....surely doing that, then registering all 6 files (including the 3rd image with a corrected satellite trail) would result in a stack without the trail ?

I find it helpful to have a seperate folder of files for each step in calibration. In my registered folder I have the files that have been calibrated/cosmetically corrected/debayered/approved&weighted and registered (ie. targetname_c_cc_d_a_r.xisf), my drizzle files and my local normalization files. When I integrate the files from this folder PI does an excellent job of removing any stray artefacts that may be left over from cosmetic correction. This updates my drizzle files and I then do a drizzle integration.

Once I've got a Master that I'm happy with I go back and delete all my files up to the point before they're registered. This leaves me with one set of calibrated/CC'd/debayered and approved files that I back up onto an HDD to use later if I do another imaging run on that target.

Dunno if that helps but as I said.....just a thought  :)

That was sort of the gist of Rob's idea; to register the satellite trail image to another image, and then do my rejection, and then go through and re-register the entirety of the images. Thats a couple additional steps when his first idea of just drawing a solid white line will let the rejection algorithm take care of it in one fell swoop.

Regards to the separate folders, thats exactly what I do, and thats why it was so easy to see that it was pulling the cosmetically corrected files. I do cc (cosmetic correction), alignment (star alignment), integration (image integration), drizzle (drizzle integration, and I also crop the images here with DyanmicCrop) dbe (dynamic background extraction), linear_fit, and then rgb folder where I stretch the images and do my LRGB combinations. Yes it does take up a lot more space, but data storage is relatively cheap these days, even on an SSD. And it makes it much easier to go back to various steps when I need to, especially when I go back to work on a project that I've spent a month or two away from. Everything is stored in a folder that syncs with Dropbox. I just wish I was better at documenting my steps for each project, but I'm getting there.

There is a 3rd way Rob......Don't include the sub with the Star trail.....

Sorry....not helpful but couldn't resist  ;)

If only! If I had at least 10 frames per filter, that would be easy, but I usually only have 4 to 6, so every frame counts.

Thanks everyone for the help and ideas.