WBPP not giving me my total integration time or subs used for my file, when splitting my DSLR OSC data into RGB channels to integrate - Forums

Question for any long time Pixinsight users. I've been using the app for a few months now. I have not been doing my initial stacking in WBPP, I use Siril. One reason for this is I don't guide, I have an older LX200 mount that PHD2 just can't get to respond fast enough for guiding so I just adjust my exposures to give me reasonably round stars and recenter the object when it drifts a little. The stars not perfect ones and WBPP really does want those good PSF values and has in the past rejected way too many of my lights, sometimes even totally failing. On the other hand I have a command I can input into Siril and get it to stack 90-100per cent of my frames, see my latest image the cocoon, Siril used 100per cent of all the lights, but in watching a new video from Pixinsight I decided to give WBPP another go round. I have stacked the last data set I acquired with The Cocoon nebula in WBPP. Anyway, my question is this. In using WBPP I processed my OSC data by splitting the RGB channels, drizzling, and then recombining the RGB channels. Hope you follow, this is on the post calibration screen of WBPP I believe. Long time users will hopefully know what I'm talking about. Watching the processing pipeline as it was doing its thing I noticed that it was splitting my channels and doing them separately, one other thing I noticed is in splitting the channels to process them it was rejecting frames in each individual channel, but the rejection was different, 45 for one channel and 56 or so for another. Of course I don't do narrow band and this is the first time I did WBPP this way. I was watching a youtube vid from Pixinsight itself on WBPP, I think it was posted just a few days ago. He made a point of saying that you should process OSC from a DSLR by selecting the split channel selection and then checking the recombined RGB tick box. Also using drizzle. When I look in the FITS header for the finished files which I have a bunch, I can't seem to find out how many of my light frames it used and the total integration time of my integrated photo. I have no idea how many total frames were used and my total time of integration. Siril always lists that info in the finished fits file it gives you after all is said and done. I don't have a problem with the way WBPP did everything, just how can I find out how many of my subs were integrated into the final image and what my combined time is. Like I said during processing each individual channel had a different number of frames rejected. So I can't just look at the processing log to see how many were finally integrated. That saying a lot just to ask how I might be able to find out how many of my subs were used and the total time of the integrated photo, also a nice thing to know is how many frames did WBPP throw out total not in each channel, these weren't individual frames like you'd get from a mono camera, maybe I'm looking at it wrong, maybe because its splitting them I should look at them that way, but the time would be 40 secs for each frame for each filter not 40secs divided by 3. The photo below was stacked in Siril and used all my light frames, are the stars perfect, no, but then neither is my setup, and I'm not selling anything just enjoying, but its no fun seeing and hour or more of your trouble get tossed in the bin or a total failure because your stars might be little elongated, which nowadays is fixable in post. Maybe there's a way to get WBPP to not be so picky, I haven't found it yet, but then I said I am new to it, but knowing the total integration time is more important right now. Thanks anyone who knows this info.

First off a disclaimer: I wouldn't touch WBPP with a barge pole.

Having said that I can opine that:

1. You shouldn't split your RAW files. PI isn't Siril (which carries some baggage from IRIS) and shan't be treated as such. Just read and calibrate them a monochrome files (same as you'd in Siril) and then debayer them.

2. Do not drizzle as you don't have the SNR and overall quality as well as the under-sampling required. There is nothing to gain and all to loose.

3. With the premises at point 1 & 2 then PI will accept happily any crap you throw at it, even trailed stars (I did it once just for the heck of it).

4. The number of integrated frames is given by the console and it is not embedded into a FITS header. Fits header are going to be mostly deprecated in PI from now on.

andrea tasselli:
First off a disclaimer: I wouldn't touch WBPP with a barge pole.

Having said that I can opine that:

1. You shouldn't split your RAW files. PI isn't Siril (which carries some baggage from IRIS) and shan't be treated as such. Just read and calibrate them a monochrome files (same as you'd in Siril) and then debayer them.

2. Do not drizzle as you don't have the SNR and overall quality as well as the under-sampling required. There is nothing to gain and all to loose.

3. With the premises at point 1 & 2 then PI will accept happily any crap you throw at it, even trailed stars (I did it once just for the heck of it).

4. The number of integrated frames is given by the console and it is not embedded into a FITS header. Fits header are going to be mostly deprecated in PI from now on.

Well now see, I totally agree with you, but that said this came from pixinsight own YouTube channel. I just figured maybe I was doing it all wrong, I’ve had the thing totally fail with data siril happily did and used all my files or at least the biggest majority. I’ve never had it fail. But unlike you I can’t get WBPP to ever accept my files if they are even remotely egg shaped. I’m happy to continue to use siril for my stacking, it even works better with multiple nights. Thinking about Astro pixel processor. Used the demo version to stack my Crab Nebula files from multiple nights and I believe it used 100% of them, but I paid enough for PI, and BXT. I am trying to save for a new mount and camera. Retired so slow goes it, but don’t they say, slow and steady wins the race. Okay well thanks for the info, and we are totally on the same page here.

Well now see, I totally agree with you, but that said this came from pixinsight own YouTube channel. I just figured maybe I was doing it all wrong, I’ve had the thing totally fail with data siril happily did and used all my files or at least the biggest majority. I’ve never had it fail. But unlike you I can’t get WBPP to ever accept my files if they are even remotely egg shaped. I’m happy to continue to use siril for my stacking, it even works better with multiple nights. Thinking about Astro pixel processor. Used the demo version to stack my Crab Nebula files from multiple nights and I believe it used 100% of them, but I paid enough for PI, and BXT. I am trying to save for a new mount and camera. Retired so slow goes it, but don’t they say, slow and steady wins the race. Okay well thanks for the info, and we are totally on the same page here.

Siril will get the job done so nothing wrong with it but if you paid good money for PI I don't see why not using it. My suggestion is to get rid of WBPP (being a script it is cumbersome and slow) and use the basic processing pipeline, which is easy enough. All you need for basic processing is shown here below:

In that order. Then:

They can all be found in the Process<Preprocessing> submenu. To fill in the field I suggest you spend some time reading about them here:

Light Vortex Astronomy - Tutorials

Hi,
WBPP is extremely complicated and most sophisticated integration script.
Here is an example. I made 80 frames at dark location and another 60 in backyard. It rejected all backyard frames. I manually (pipeline is presented above) integrated all these 60 frames using PI.
Then, I measured FWHM, eccentricity, SNR and stars in integrated frames. Only 80 integrated frames by WBPP was the best, adding 60 frames manually to those 80 frames compromised quality.

My advice. Don’t be frustrated. Watch all WBPP related YouTube Adam Block videos. There are 30 of them! Take your time to master WBPP. It will pay in long run.

As far as current results, it will be great to see data of integrated files. Is SIRIL integrated file better than WBPP integrated with rejections?

CS!

Armen

AnaTa:
Hi,
WBPP is extremely complicated and most sophisticated integration script.
Here is an example. I made 80 frames at dark location and another 60 in backyard. It rejected all backyard frames. I manually integrated all these 60 frames using PI.
Then, I measured FWHM, eccentricity, SNR and stars in integrated frames. Only 80 integrated frames by WBPP was the best, adding 60 frames manually to those 80 frames compromised quality.

My advice. Don’t be frustrated. Watch all WBPP related YouTube Adam Block videos. There are 30 of them! Take your time to master WBPP. It will pay in long run.

As far as current results, it will be great to see data of integrated files. Is SIRIL integrated file better than WBPP integrated with rejections?

CS!

Armen

Ditto - WBPP is much better than any other stacking solution I have used. Far fewer artifacts & the autocropping is excellent. Key thing here is what was mentioned in another post, you should not be splitting your RAW files prior to stacking. Stack them as OSC files, then split them in PI afterwards using the RGB split tool. I do this when using a dual-band filter to get Ha and Oiii from by OSC camera (then integrate using Forax for example).

andrea tasselli:
Well now see, I totally agree with you, but that said this came from pixinsight own YouTube channel. I just figured maybe I was doing it all wrong, I’ve had the thing totally fail with data siril happily did and used all my files or at least the biggest majority. I’ve never had it fail. But unlike you I can’t get WBPP to ever accept my files if they are even remotely egg shaped. I’m happy to continue to use siril for my stacking, it even works better with multiple nights. Thinking about Astro pixel processor. Used the demo version to stack my Crab Nebula files from multiple nights and I believe it used 100% of them, but I paid enough for PI, and BXT. I am trying to save for a new mount and camera. Retired so slow goes it, but don’t they say, slow and steady wins the race. Okay well thanks for the info, and we are totally on the same page here.

Siril will get the job done so nothing wrong with it but if you paid good money for PI I don't see why not using it. My suggestion is to get rid of WBPP (being a script it is cumbersome and slow) and use the basic processing pipeline, which is easy enough. All you need for basic processing is shown here below:

In that order. Then:

They can all be found in the Process<Preprocessing> submenu. To fill in the field I suggest you spend some time reading about them here:

Light Vortex Astronomy - Tutorials

Finally somebody has shown me the way, and that’s no joke. Thank you for showing me the steps to do it manually. Everyone just gets into this whole thing about stuff for over an hour and I kinda say I get bored. I’ll look over those tutorials and I’m familiar with light vortex to some degree, but really thanks for the process I need to do it myself. Big help. I saw some of that a while ago but that was before I acquired the app, a use it or lose it thing and I lost it. I do remember you tell each process where to put your files and then use those for the next step, it puts a designator at the end of the file name like cc for cosmetic correction or a d for Debayered. So I do remember it somewhat. Thanks again.

AnaTa:
Hi,
WBPP is extremely complicated and most sophisticated integration script.
Here is an example. I made 80 frames at dark location and another 60 in backyard. It rejected all backyard frames. I manually integrated all these 60 frames using PI.
Then, I measured FWHM, eccentricity, SNR and stars in integrated frames. Only 80 integrated frames by WBPP was the best, adding 60 frames manually to those 80 frames compromised quality.

My advice. Don’t be frustrated. Watch all WBPP related YouTube Adam Block videos. There are 30 of them! Take your time to master WBPP. It will pay in long run.

As far as current results, it will be great to see data of integrated files. Is SIRIL integrated file better than WBPP integrated with rejections?

CS!

Armen

Ditto - WBPP is much better than any other stacking solution I have used. Far fewer artifacts & the autocropping is excellent. Key thing here is what was mentioned in another post, you should not be splitting your RAW files prior to stacking. Stack them as OSC files, then split them in PI afterwards using the RGB split tool. I do this when using a dual-band filter to get Ha and Oiii from by OSC camera (then integrate using Forax for example).

The guy on the video said to use the splitting routine in WBPP. Separate, then process and the recombine. It gives me all the masters after this. I’ll just have to run the data, see what I get.

andrea tasselli:
First off a disclaimer: I wouldn't touch WBPP with a barge pole.

Having said that I can opine that:

1. You shouldn't split your RAW files. PI isn't Siril (which carries some baggage from IRIS) and shan't be treated as such. Just read and calibrate them a monochrome files (same as you'd in Siril) and then debayer them.

2. Do not drizzle as you don't have the SNR and overall quality as well as the under-sampling required. There is nothing to gain and all to loose.

3. With the premises at point 1 & 2 then PI will accept happily any crap you throw at it, even trailed stars (I did it once just for the heck of it).

4. The number of integrated frames is given by the console and it is not embedded into a FITS header. Fits header are going to be mostly deprecated in PI from now on.

Statement #2 is misleading or incorrect depending on how you look at it. Drizzle 1x1 (without upsampling) has benefits and may actually be the standard with respect to OSC data. CFA drizzle avoids interpolation effects that can interfere with good color calibration. See the relevant section in the SPCC documentation.

-adam

Anthony,

The debayer process is what splits the calibrated, cosmetic corrected files into separate R, G, B files. WBPP handles this automatically if the told it to split into separate RGB files. There a advantages to splitting to get better star alignment of the individual channels. I normally processed all my color camera data by splitting the channel and recombining.

Andrea is correct that it makes no sense for you to Drizzle final data, if your not dithering during acquisition and your data is not under sampled. Drizzle works best with dithered under sampled data.

You haven't really provided any information about when the frames are be rejected. Are they being rejected in image registration or image integration. If image registration is failing try adjusting the Image Registration parameters to get more of your individual frame accepted.

If images are being rejected during Image Integration, the Minimum Weight may be too high for you data. Setting this value to zero will eliminate Image Integration rejection that are caused by excessive PSF variations between you individual frames.

Unfortunately, the only way that you can determine your total integration time of you image is by knowing how many frames were actually integrated and calculating this time. WBPP will provide the total integration time of all the frames but this number is not adjusted if frames are rejected during later in the process.

Hope this helps,
Michael

Michael Broyles:
Anthony,

The debayer process is what splits the calibrated, cosmetic corrected files into separate R, G, B files. WBPP handles this automatically if the told it to split into separate RGB files. There a advantages to splitting to get better star alignment of the individual channels. I normally processed all my color camera data by splitting the channel and recombining.

Andrea is correct that it makes no sense for you to Drizzle final data, if your not dithering during acquisition and your data is not under sampled. Drizzle works best with dithered under sampled data.

You haven't really provided any information about when the frames are be rejected. Are they being rejected in image registration or image integration. If image registration is failing try adjusting the Image Registration parameters to get more of your individual frame accepted.

If images are being rejected during Image Integration, the Minimum Weight may be too high for you data. Setting this value to zero will eliminate Image Integration rejection that are caused by excessive PSF variations between you individual frames.

Unfortunately, the only way that you can determine your total integration time of you image is by knowing how many frames were actually integrated and calculating this time. WBPP will provide the total integration time of all the frames but this number is not adjusted if frames are rejected during later in the process.

Hope this helps,
Michael

*** I guess I will keep at it... please see my comment above. This is not a full accounting of the usefulness of drizzle (1x1).
-adam

AnaTa:
Hi,
WBPP is extremely complicated and most sophisticated integration script.
Here is an example. I made 80 frames at dark location and another 60 in backyard. It rejected all backyard frames. I manually (pipeline is presented above) integrated all these 60 frames using PI.
Then, I measured FWHM, eccentricity, SNR and stars in integrated frames. Only 80 integrated frames by WBPP was the best, adding 60 frames manually to those 80 frames compromised quality.

My advice. Don’t be frustrated. Watch all WBPP related YouTube Adam Block videos. There are 30 of them! Take your time to master WBPP. It will pay in long run.

As far as current results, it will be great to see data of integrated files. Is SIRIL integrated file better than WBPP integrated with rejections?

CS!

Armen

actually my question that started the thread was how do I find out how many subs WBPP used for the integration. It kinda got into this whole which is better thing, siril or WBPP. I use them both and yes WBPP fails on more subs than siril, I do think the results in WBPP are better. I do hate it rejecting my frames when I can’t really see a reason. I don’t have the ability to give it pristine data, and I would like a good result, just don’t be so picky. If you look at my M51 shot, this is an example of siril gave me a photo, WBPP, did a total fail. Said, need at least I think 3 frames to stack, and couldn’t even find 3 frames. That to me is totally unacceptable, but this is all my opinion. I do use PI for everything else, just not stacking right now. Like I said I just wanted to know how many frames it used because telling it to separate the channels, it gave me different rejection numbers depending on the channel it was doing. So I really don’t know how many it rejected total. Really that’s all I wanted to know. Happy for the info though. Always appreciate any help I can get. And yes it is a very complicated script that has a steep learning curve. Looking at PI’s YouTube channel I saw a newly released vid on WBPP, so of course I wanted to check it out and he said shooting with a OSC DSLR, you should select split the channels, tick the recombine box and drizzle. Being PI’s own channel from the guys who publish the software I thought the info was legit and maybe I was doing it all wrong so I shot my latest data set through it, got all my master lights and when I went to check frames used I saw nothing along with total integration time for the stacked photo, which siril writes in the fits header and renames the file with that info. So actually that’s all I was asking. But again thanks for your response. And yeah when WBPP likes my data it is better. Just I never know if it’s gonna like me or reject me, and I don’t do well with rejection, lol

Adam Block:
andrea tasselli:
First off a disclaimer: I wouldn't touch WBPP with a barge pole.

Having said that I can opine that:

1. You shouldn't split your RAW files. PI isn't Siril (which carries some baggage from IRIS) and shan't be treated as such. Just read and calibrate them a monochrome files (same as you'd in Siril) and then debayer them.

2. Do not drizzle as you don't have the SNR and overall quality as well as the under-sampling required. There is nothing to gain and all to loose.

3. With the premises at point 1 & 2 then PI will accept happily any crap you throw at it, even trailed stars (I did it once just for the heck of it).

4. The number of integrated frames is given by the console and it is not embedded into a FITS header. Fits header are going to be mostly deprecated in PI from now on.

Statement #2 is misleading or incorrect depending on how you look at it. Drizzle 1x1 (without upsampling) has benefits and may actually be the standard with respect to OSC data. CFA drizzle avoids interpolation effects that can interfere with good color calibration. See the relevant section in the SPCC documentation.

-adam

There you go, thanks Adam, exactly what the narrator said if you don’t drizzle, would throw SPCC off. He showed an example of an extreme magnified star in 2 frames and blinking between the 2, and the blue channel, I believe, was off. Not by much but I guess it was enough. So that’s why I drizzled the data. They said it, so I did it. And truthfully that was not my concern, I only wanted to know who to find the rejection number so I could figure out how much time I ended up with. Just like I do with your info BTW, if you say it I take it to the bank and deposit it.

Adam Block:
andrea tasselli:
First off a disclaimer: I wouldn't touch WBPP with a barge pole.

Having said that I can opine that:

1. You shouldn't split your RAW files. PI isn't Siril (which carries some baggage from IRIS) and shan't be treated as such. Just read and calibrate them a monochrome files (same as you'd in Siril) and then debayer them.

2. Do not drizzle as you don't have the SNR and overall quality as well as the under-sampling required. There is nothing to gain and all to loose.

3. With the premises at point 1 & 2 then PI will accept happily any crap you throw at it, even trailed stars (I did it once just for the heck of it).

4. The number of integrated frames is given by the console and it is not embedded into a FITS header. Fits header are going to be mostly deprecated in PI from now on.

Statement #2 is misleading or incorrect depending on how you look at it. Drizzle 1x1 (without upsampling) has benefits and may actually be the standard with respect to OSC data. CFA drizzle avoids interpolation effects that can interfere with good color calibration. See the relevant section in the SPCC documentation.

-adam

There you go, thanks Adam, exactly what the narrator said if you don’t drizzle, would throw SPCC off. He showed an example of an extreme magnified star in 2 frames and blinking between the 2, and the blue channel, I believe, was off. Not by much but I guess it was enough. So that’s why I drizzled the data. They said it, so I did it. And truthfully that was not my concern, I only wanted to know who to find the rejection number so I could figure out how much time I ended up with. Just like I do with your info BTW, if you say it I take it to the bank and deposit it.

There are a couple of places to find the number of rejected frames... If they are rejected before registration- you can literally go into your registered folder and count the number of frames there... these should be the successful ones. The execution monitor shows the information. The History in the headers of integrated images I believe shows the number of files used as well.

Concerning the tolerance of star quality. There is now a new method in PixInsight which you need to tune. There is a "minimum structure" size that affects the size it will accept as stars. You can also adjust the star "Distortion" parameter so that your elongated stars will be detected as real star sources. You can find these in the registration (Star ALignment) setup.

These two parameters (and maybe the SNR parameter) should allow you to use any star quality you have.

-adam

Adam Block:
Adam Block:
andrea tasselli:
First off a disclaimer: I wouldn't touch WBPP with a barge pole.

Having said that I can opine that:

1. You shouldn't split your RAW files. PI isn't Siril (which carries some baggage from IRIS) and shan't be treated as such. Just read and calibrate them a monochrome files (same as you'd in Siril) and then debayer them.

2. Do not drizzle as you don't have the SNR and overall quality as well as the under-sampling required. There is nothing to gain and all to loose.

3. With the premises at point 1 & 2 then PI will accept happily any crap you throw at it, even trailed stars (I did it once just for the heck of it).

4. The number of integrated frames is given by the console and it is not embedded into a FITS header. Fits header are going to be mostly deprecated in PI from now on.

Statement #2 is misleading or incorrect depending on how you look at it. Drizzle 1x1 (without upsampling) has benefits and may actually be the standard with respect to OSC data. CFA drizzle avoids interpolation effects that can interfere with good color calibration. See the relevant section in the SPCC documentation.

-adam

There you go, thanks Adam, exactly what the narrator said if you don’t drizzle, would throw SPCC off. He showed an example of an extreme magnified star in 2 frames and blinking between the 2, and the blue channel, I believe, was off. Not by much but I guess it was enough. So that’s why I drizzled the data. They said it, so I did it. And truthfully that was not my concern, I only wanted to know who to find the rejection number so I could figure out how much time I ended up with. Just like I do with your info BTW, if you say it I take it to the bank and deposit it.

There are a couple of places to find the number of rejected frames... If they are rejected before registration- you can literally go into your registered folder and count the number of frames there... these should be the successful ones. The execution monitor shows the information. The History in the headers of integrated images I believe shows the number of files used as well.

Concerning the tolerance of star quality. There is now a new method in PixInsight which you need to tune. There is a "minimum structure" size that affects the size it will accept as stars. You can also adjust the star "Distortion" parameter so that your elongated stars will be detected as real star sources. You can find these in the registration (Star ALignment) setup.

These two parameters (and maybe the SNR parameter) should allow you to use any star quality you have.

-adam

I'm not exactly sure where I might find those settings, and are they only in the newest update, which I didn't do cause I still use the EZ suite of scripts. I may update though if those setting are in the newest version. I know they also just posted even a newer update because of some bugs or something. I'm not seeing the setting in WBPP, but again they may only be in the newest update. I'm on the one that was just before the update last month. And I can't tell you enough how much I appreciate your help, you are my PI guru. ;) version that I have 1.8.9-1 I don't usually jump right on an update, I give it a couple of months.

Anthony,

The setting for Star Alignment can be found in WBPP on the Lights tab. On the right hand panel Image Registration-> Registration parameters. The Image Integration->Integration parameters is where you can find the Minimum weight setting.

Michael

Adam Block:
Statement #2 is misleading or incorrect depending on how you look at it. Drizzle 1x1 (without upsampling) has benefits and may actually be the standard with respect to OSC data. CFA drizzle avoids interpolation effects that can interfere with good color calibration. See the relevant section in the SPCC documentation.

-adam

The OP was referring (in my view) to the standard 2x drizzling not CFA drizzling. But either way I don't see much an advantage with CFA drizzle if the data is seriously affected by tracking issues (as a minimum) and certainly using CFA drizzle will reduce the final SNR which should have been avoided as per the requirements of the OP.

Having used CFA drizzle for the past year I can say that the gain is marginal in my datasets but the loss of SNR is real.

I avoid the script. It doesn't seem to fit my workflow and I like seeing to results of my calibration as I go each morning. Over in PI most questions are about the script and not the processes. Learning PI is useful.

andrea tasselli:
Adam Block:
Statement #2 is misleading or incorrect depending on how you look at it. Drizzle 1x1 (without upsampling) has benefits and may actually be the standard with respect to OSC data. CFA drizzle avoids interpolation effects that can interfere with good color calibration. See the relevant section in the SPCC documentation.

-adam

The OP was referring (in my view) to the standard 2x drizzling not CFA drizzling. But either way I don't see much an advantage with CFA drizzle if the data is seriously affected by tracking issues (as a minimum) and certainly using CFA drizzle will reduce the final SNR which should have been avoided as per the requirements of the OP.

Having used CFA drizzle for the past year I can say that the gain is marginal in my datasets but the loss of SNR is real.

Interesting.
If image scale is >1.5”/pixel, if dithering is correct that is enough shift in RA and DEC, if Blur XT is used, then results from drizzling are dramatic; every time I have used
Again, all these conditions must to see drizzling outcome

CS!

*** IType your reply here ***

My image scale is <1.5"/px mostly, so there you are…

andrea tasselli:
My image scale is <1.5"/px mostly, so there you are...

Excellent. Now you know when to drizzle.
CS!

You know it never ceases to amaze how these forum threads go. I asked a simple question, how do I find the total number of frames that PI integrated using WBPP along with the total integration time and somewhere along the line we got to taking about drizzling and whether WBPP is better than Siril. Actually no one has addressed my question but that’s cool. Interesting comments. Even though my question still stands. I only brought up how I did the process to help understand why I can’t get the total frames that was used because I had WBPP split the channels and they were calibrated separately and then recombined with different numbers of rejected frames per channel. I just don’t know how to figure that. If I had shot mono through individual filters and then imported them that way it’d make sense but I let WBPP split the channels and then recombine them so I don’t know how to interpret the info in the process log for a total frame count. Hence the title of my query for this forum thread.

You know it never ceases to amaze how these forum threads go. I asked a simple question, how do I find the total number of frames that PI integrated using WBPP along with the total integration time and somewhere along the line we got to taking about drizzling and whether WBPP is better than Siril. Actually no one has addressed my question but that’s cool. Interesting comments. Even though my question still stands. I only brought up how I did the process to help understand why I can’t get the total frames that was used because I had WBPP split the channels and they were calibrated separately and then recombined with different numbers of rejected frames per channel. I just don’t know how to figure that. If I had shot mono through individual filters and then imported them that way it’d make sense but I let WBPP split the channels and then recombine them so I don’t know how to interpret the info in the process log for a total frame count. Hence the title of my query for this forum thread.

I think two people (Adam Block and Michael Brooke’s) directly answered your question. Did you try their suggested settings?

AnaTa:
You know it never ceases to amaze how these forum threads go. I asked a simple question, how do I find the total number of frames that PI integrated using WBPP along with the total integration time and somewhere along the line we got to taking about drizzling and whether WBPP is better than Siril. Actually no one has addressed my question but that’s cool. Interesting comments. Even though my question still stands. I only brought up how I did the process to help understand why I can’t get the total frames that was used because I had WBPP split the channels and they were calibrated separately and then recombined with different numbers of rejected frames per channel. I just don’t know how to figure that. If I had shot mono through individual filters and then imported them that way it’d make sense but I let WBPP split the channels and then recombine them so I don’t know how to interpret the info in the process log for a total frame count. Hence the title of my query for this forum thread.

I think two people (Adam Block and Michael Brooke’s) directly answered your question. Did you try their suggested settings?

I did and no not helpful. Reason being, with WBPP splitting one file into 3 channels RGB then calibrating and registering them as separate images it was giving different amount of rejected frames for each channel. So that’s my query. If I had taken a light sub through an R, B, G filter I’d have around 150 images per filter. Then rejecting frames would make sense. I’d know how many I had left in each channel. But splitting one file into three and then doing it’s thing and then recombining them I have no idea how many it rejected total. That’s what I’m looking for. What the final RGB image was the result of and what the integration time of that one file was. I get all the masters, one for red, cropped and not cropped, blue same, green same then I get drizzled files for each channel then I get an RGB image autocrop and not cropped. Bunch of finished files but no info. I guess I could take each channel subtract the number of rejected files and then total what’s left I might have an idea. For that I need to know did WBPP when it split each file into RGB did the total file count still be the same or was it divided by three or multiples by 3. See my problem. If I took 150 40sec images through each filter I’d start with 450 40sec images, and if it told me it rejected say 40, 65, 54 files respectively in each channel then because I started with 450 images, 150 for each channel, I could do the math because I would have a set number of images to start with, but with WBPP splitting each of 400 40sec images into 3 channels, do I have 1200 total images or just 400 or is it 400 divided by 3 and if that’s the case is the time divided by 3. Complicated isn’t it. And if I still only have 400 40sec images how many am I left with after it rejects images in each channel. I don’t know how to figure it. And in answer to your question, no they haven’t. Adam came the closes but I deleted those images and WBPP creates so many images after each process I don’t really have a clue which ones it’s using for the final stack. This has gotten way more complicated than I originally thought. Never doing that again, at least for images shot through my DSLR. If I seem to ramble it’s because I was up last night till 4 in the morning adding data to my IC5146 image so I’m very tired. Thanks to everyone who has replied. I appreciate the info on the other topics for sure.

Anthony,

Let me see if I can explain:

1) WBPP will split your RAW RGB images into separate R, G, and B file. If you have 400 RAW file, you will have 400 R, 400 G, and 400 B files for a total of 1200 files. If none of these files are rejected by WBPP and they are each 40 sec, your total integration time will be 400 * 40s = 16000s or 4.45 hours.

2) If WBPP Image Registration fail to being unable to file align some stars, registration files will not be generated by WBPP and these images will need to be subtracted from the image count. So if R rejected 10 files, G reject 10 files, and B rejected 20 files the total integration time will be 400 - 40 = 360 * 40s = 14400s or 4 hours.

3) Image Integration now only has 360 files to integrate. However, Image Integration may also reject files if the calculated weight of the file is lower than Minimum weigh value. Let say that once again 10 R files are rejected, 10 G files are rejected, and 20 B files are rejected. This means that the total integration time is not 360 - 40 = 320 * 40s = 12800s or 3.55 hours.

As Adam indicated, you can determine the number of images reject by image registration by counting registration XISF files that were created by WBPP of the pipeline will so the number of active images for each channel during the next step in the pipeline.

Images rejected during integration base of the weight is a little harder to determine. But the process logs contain detail information stating the number of files integrated, so check the logs. You can also count the number of XDRZ files that were update by the image integration.

The total integration time for RAW Color data the total number of split files divided by 3. In other words, if you with 400 files, after splitting you have 1200 R, B, G files but the total integration is 1200 / 3 = 400 files. This is because the RAW color data was capture is a single exposure unlike Mono images which acquire data in three separate exposure for each filter.

Hope this answers your question.

Michael