chris_todd
Well-known member
What's the best place (time? position?) in the workflow to use the Canon banding script?
Canon banding script - where in the workflow?
- Thread starter chris_todd
- Start date
Alejandro Tombolini
PixInsight Ambassador
At the beginning, when image is linear. Could be for example before DBE.
chris_todd
Well-known member
So after ImageIntegration? Any reason not to apply it, for example, to the RAW lights (or darks, or bias, or flats)?Alejandro Tombolini said:
i use it right after integration.
one thing to watch out for is that if you are working on a multi-night project and your position angle changes slightly from night to night, that the banding will no longer be totally horizontal when you integrate everything together. if the banding is really bad you might have to stack each night separately, apply the banding reduction, and then stack the stacks...
one thing to watch out for is that if you are working on a multi-night project and your position angle changes slightly from night to night, that the banding will no longer be totally horizontal when you integrate everything together. if the banding is really bad you might have to stack each night separately, apply the banding reduction, and then stack the stacks...
you'd want to apply it to your calibrated lights, after debayering them but before aligning them for the same reason i mentioned above... problem is as far as i know there's no way to run it in a batch, and even so you might have to tweak the parameters and then you're doing all your lights one by one. my last project had 121 lights so i'd be insane by now (or more insane) if i had to run CBR on each one.
chris_todd
Well-known member
pfile said:
That kind of scenario is why I wondered whether it would make sense to apply it at the RAW stage, before integration.
georg.viehoever
Well-known member
Hi all,
I am always amazed to see how many people are actually using this script. I never expected this to happen.
- The script can be used in a batch fashion on many images. 1. Define your parameters, and use the blue triangle to drag the instance to your workspace. 2. Use ImageContainer to define all the images to which you want to apply it. 3. Drag ImageContainer to instance on workspace. I used this procedure to create some timelaps videos.
- I usually apply it to a single image after calibration, before further processing. This has the advantage that image defects are easier to distinguish from (patterned) noise than in images not yet integrated. Also, it requires application to only one image instead of the whole stack. On the other hand, at this point in time, image defects have already spread over larger regions and may have been rotated due to alignment+integration, and may have spread to neighboring pixels/other color channels due to debayering.
- I am not sure if application to calibrated CFA images (not yet debayered, aligned, stacked) has a benefit. On the positive side is that defects have not yet spread due to debayering, alignment, integration. In the negative side is the low SNR of those frames. We would need to test. It is not yet possible with the current script, because it cannot handle CFA images.
- Same for application directly to the RAW files (dark, flat, bias+light). In theory, this may improve the results of the calibration process because it would remove an unwanted noise source. We would need to test. It is not yet possible with the current script, because it cannot handle CFA images.
It makes a lot of sense to translate this script into a proper module:
- Proper "blue triangle" functionality. While dragging to the desktop works fine, the entry in the processing history of an image only records the default parameters, not those actually used.
- Speed. C++ should be much faster the PJSR
- It may be possible to integrate the module with the proper Realtime Preview feature of PI
- While working on it, one may want to add additional functionality:
-- work on horizontal and vertical banding (not sure if arbitrary angles make sense)
-- direct work on CFA image. I think that a solution handling CFA images as four channels (2 green channels) would be sufficient-it would not even need to know the actual Bayer pattern. The Bayer pattern may be required to support proper preview.
-- (optionally) separate parametes for each channel (I find that red has significantly different noise characteristics the G or B.)
If someone wants to work on it or translate to PCL, feel free to do so - I would be glad to see it improved. Just leave it under a free open source license compatible with PI (e.g. BSD), and mention the parents (Jens Dierks, the author if Fitworks (http://www.fitswork.de/software/impressum.php) who permitted reimplementation of this functionality based on his program, and myself) in the copyright message.
Georg
I am always amazed to see how many people are actually using this script. I never expected this to happen.
- The script can be used in a batch fashion on many images. 1. Define your parameters, and use the blue triangle to drag the instance to your workspace. 2. Use ImageContainer to define all the images to which you want to apply it. 3. Drag ImageContainer to instance on workspace. I used this procedure to create some timelaps videos.
- I usually apply it to a single image after calibration, before further processing. This has the advantage that image defects are easier to distinguish from (patterned) noise than in images not yet integrated. Also, it requires application to only one image instead of the whole stack. On the other hand, at this point in time, image defects have already spread over larger regions and may have been rotated due to alignment+integration, and may have spread to neighboring pixels/other color channels due to debayering.
- I am not sure if application to calibrated CFA images (not yet debayered, aligned, stacked) has a benefit. On the positive side is that defects have not yet spread due to debayering, alignment, integration. In the negative side is the low SNR of those frames. We would need to test. It is not yet possible with the current script, because it cannot handle CFA images.
- Same for application directly to the RAW files (dark, flat, bias+light). In theory, this may improve the results of the calibration process because it would remove an unwanted noise source. We would need to test. It is not yet possible with the current script, because it cannot handle CFA images.
It makes a lot of sense to translate this script into a proper module:
- Proper "blue triangle" functionality. While dragging to the desktop works fine, the entry in the processing history of an image only records the default parameters, not those actually used.
- Speed. C++ should be much faster the PJSR
- It may be possible to integrate the module with the proper Realtime Preview feature of PI
- While working on it, one may want to add additional functionality:
-- work on horizontal and vertical banding (not sure if arbitrary angles make sense)
-- direct work on CFA image. I think that a solution handling CFA images as four channels (2 green channels) would be sufficient-it would not even need to know the actual Bayer pattern. The Bayer pattern may be required to support proper preview.
-- (optionally) separate parametes for each channel (I find that red has significantly different noise characteristics the G or B.)
If someone wants to work on it or translate to PCL, feel free to do so - I would be glad to see it improved. Just leave it under a free open source license compatible with PI (e.g. BSD), and mention the parents (Jens Dierks, the author if Fitworks (http://www.fitswork.de/software/impressum.php) who permitted reimplementation of this functionality based on his program, and myself) in the copyright message.
Georg
chris_todd
Well-known member
Georg,
I tried out the script on a master bias frame last night, and it had a noticable result. I did not have time to try applying it to all the bias frames before integration, nor did I have time to try it against the other calibration frames, but I will try to find time to do that experiment this weekend. Thank you for describing how to use image container to batch this.
Chris
I tried out the script on a master bias frame last night, and it had a noticable result. I did not have time to try applying it to all the bias frames before integration, nor did I have time to try it against the other calibration frames, but I will try to find time to do that experiment this weekend. Thank you for describing how to use image container to batch this.
Chris
by the way, it's not that i said i'd have to run CBR one each one individually due to not knowing how to use ImageContainer. instead, i find that every stack is different, and so i believe every sub is different, in the exact settings that are needed to remove the banding without damaging the image. that kind of precludes scripting this operation and favors running it on stacks vs. subs due to the amount of work it represents.
old thread... but for the first time i used ImageContainer to apply CBR to 94 calibrated, debayered subs. in this particular case i can not see the banding noise in the subs, but it is definitely there in the final result. it's a multi-night project and the angles don't line up in the integrated result.
i decided to just go with the default amount of banding reduction with the default amount of highlight protection, and the result was absolutely great. no banding noise to be found in the integrated stack, and as far as i can tell the image was undamaged.
so... new workflow for me, i guess, though now i have to stop BatchPreprocessing before registration and do that step manually.
i decided to just go with the default amount of banding reduction with the default amount of highlight protection, and the result was absolutely great. no banding noise to be found in the integrated stack, and as far as i can tell the image was undamaged.
so... new workflow for me, i guess, though now i have to stop BatchPreprocessing before registration and do that step manually.
Alejandro Tombolini
PixInsight Ambassador
That is exellent!, good to know.
Saludos, Alejandro
Saludos, Alejandro