1.81
#...
·
·
2
likes
|
|---|
|
I've been utilizing Blink more often lately to examine my images. One thing I've noticed that I didn't catch on the ASIAir previews or ZWO's PC app is that the backgrounds from an imaging session vary in brightness. This is definitely from changes in sky brightness throughout the night but are my lighter background images still usable in stacking or is this introducing problems into the final image. I usually begin a session at astronomical night and run before sunrise. What I've been doing is discarding a lot of data, usually in the first hour and last hour of imaging. I have no problem discarding an image with a very bright white background but not sure if the more grey backgrounds are ok to use. I was also wondering if this was a limitation of the STF stretch that's applied to all the images and the data is overall fine to use if overall no problems with the image |
4.95
#...
·
·
2
likes
|
|---|
|
WBPP stacking/integration takes long enough that I don't want to have any images in the final mix that I feel are going to degrade the product. That being said, there are "grey areas" (pun completely intended). I have corrected a few that are slightly grey, yet super sharp and included them in the stack. But I always have images that are thrown out by the program and I have not investigated to see if my corrected subs are the ones getting kicked out. I suspect they are. Its always interesting to see how STF handles subs in batch when in Blink. Early on I wasn't even using it. Sometimes I feel like its one of those functions (STF in Blink) that results in stirring the pot a little too much on the front end. Additionally, I have no idea what ASIair previews look like. The ZWO FitsViewer doesn't do as good a job of preview stretching is NINA in my opinion. So I usually just go with that and have a pretty good idea of what is garbage straight away. So basically my opinion is a little bit of grey in the background is probably ok if the overall image is sharp. But I wouldn't go too far. |
|
1.81
#...
·
|
|---|
| Thank you for the response. Yeah I feel like I'm being too picky in what I'm discarding which ends up being hours of data and results in an additional night of imaging. The DSO itself looks great with nice sharp stars so I would assume using some "greyer" background images wouldn't hurt especially if nebulosity isn't washed out |
3.61
#...
·
·
12
likes
|
|---|
|
One thing to note is that I believe Blink by defauly applies the same stretch to each image. I always click the top icon within Blink to compute individual stretches. This makes each image to image a lot more coherent in my experience. I mainly use Blink to detect tracking errors. Otherwise, I like to let WBPP "do its thing" when it comes to PSF weights. |
|
1.81
#...
·
·
3
likes
|
|---|
One thing to note is that I believe Blink by defauly applies the same stretch to each image. I always click the top icon within Blink to compute individual stretches. This makes each image to image a lot more coherent in my experience. It does, which was making me think I may have been throwing out data which was totally usable but the stretch applied to the image was making me think twice about it. Thank you for the tip on Blink, I didn't know about that. |
2.41
#...
·
·
2
likes
|
|---|
|
You will want to click the middle top icon "Apply an automatic histogram transformation to all images". This will equalize everything that is in the blink list. It's just a view transformation, your data will remain as-is. In most cases, you probably won't see much of a difference going with defaults in WBPP stacking, but if you really wanted to maximize data time closer to meridian with less atmosphere and early/late sky glow influencing weighting, you can going with 'PSF Scale SNR' in Subframe weighting -> Weights dropdown. For most of us, that won't make that much difference changing that parameter so I'm just mentioning it in full transparency if you are really concerned about sky glow affecting the stacking. Try it with and without changing the setting to see if it really matters for your equipment/acquisition. |
11.07
#...
·
·
16
likes
|
|---|
|
You should be very cautious about throwing out data based on the blink result. Before you assess the subs in any way you have to equalize the STF stretch. Push the button with the histogram symbol immediately after loading the images. This should allow you to compare the subs with confidence. Before you reject any subs outright, remember this: 1) WBPP will weight subs based on their signal to noise ratio. If you really do have subs with extremely bright backgrounds they will receive and extremely low weight by WBPP because the SNR will be very low. 2) WBPP also has excellent rejection options for getting rid of satellite and jet trails. I would only use Blink to fully reject a sub based on trails if you've already tried to resolve remnant trails with rejection during image integration (either in WBPP or stand alone). Occasionally I will have a sub with a stubborn trail I reject in Blink but the vast majority of subs with trails are fine. 3) Subs with trailed stars and low resolution due to seeing, guiding or focus should be assessed empirically using Subframe Selector no Blink. You can set your own threshold for FWHM and approve the subs in Subframe Selector. I usually make my elongation cut off .6 but again, use measurements in S.S. not eyeballs in Blink So when do I use Blink? The number one reason I reject subs in Blink is transparency issues. This is when I see large glowing halos around the bright stars because the sky got hazy or there with high clouds. These can look like signal to WBPP and actually be preferred to the good subs if they predominate. The other thing I look for is strong gradients that appear only in a certain portion of the night. Some gradient is OK and can be corrected in DBE. But strong gradients can really mess things up and can indicate others issues. Kevin |
3.71
#...
·
·
3
likes
|
|---|
| What everyone said 😎. I use blink just to eliminate airplane crossings and when I try to image in the trees 😎. Then I use PI’s subframe selector and finally let WBPP do its thing after that. |
0.00
#...
·
·
1
like
|
|---|
|
I think you already have your answer above really in that if you use WBPP that should generally take care of everything so that the poorer images do not compromise the better ones. I still use Blink and would discard some frames if they look terrible with little useful detail of the target itself, and any other dodgy frames with star trails etc, I also tend to use both methods of stretch in Blink, using the one that stretches individually first which shows what detail of the target is within the image, and obviously if almost nothing discard straight away and then maybe select the best image and blink with all images stretched the same as that to see how light the backgrounds really are. Whether I discard any of the lighter backgrounds may depend on my total number of frames I actually have. If I don't have that many then sometimes there is little choice and have to try to keep as many as possible but if I have maybe imaged over a few nights and have an abundance of frames I may be a little more critical but still would keep most of the frames and let WBPP sort it out. That said I have never tried to see how much effect keeping poor frames in has on the final image, I would think loosing a few images that WBPP would give little weight to would not have much visible difference. |
0.90
#...
·
|
|---|
Robert Khoury: You can Linearfit subs of varying light to help with colorcalibrationlater on. Roger |
|
1.81
#...
·
|
|---|
| Ugh ok yeah I was fooled by Blink. I do utilize WBPP with settings I got from Adam Block's tutorial which have worked well for me. I did delete from Ha data like this but still have my Oiii "rejects" available. I appreciate everyone's input into this subject. |
0.00
#...
·
·
1
like
|
|---|
|
If you weight your subs based on the number of stars (or similar metric) it should prioritize the frames with a lower background. That's the approach I would take instead of throwing away the data. I would be a good experiment to compare the two approaches. |
0.00
#...
·
|
|---|
|
I really only started using Blink recently when I was getting tired of hitting next on the ASI image previewer windows app 300 times in a row for each night of data I needed to review and I noticed that it definitely got super bright 2/3rds of the way through my exposures and I was quite surprised! However, it doesn't match up with what my ASI app shows when I go through the frames manually, which is usually only the last handful of frames when the sun comes up enough. I didn't trust blink because of this and manually looked with the other app to when it appeared like it was being degraded and figured I'd delete from there and let WBPP figure out the rest. I've never really noticed many frames being rejected when I do it this way. Again, I'm really pretty new to Blink and it was concerning to see how bright my exposures appeared when I know I didn't take pics that long into sunrise, so I figured it must be something weird with their auto-stretch algorithm in blink. Hopefully that is true and I'm not just dumping loads of bad pics into my processing! |
0.00
#...
·
·
1
like
|
|---|
| I have been using Sub frame selector first to eliminate all the Subs with FWHM, SNR that are over/under my self idealized limit as well as any that have less than the average star count so when i do the BLINK i am then only looking for artifacts like Starlink, meteors and the like....I do not worry about lighter frames than slightly darker since i eliminated most of those in SFS, i end up taking a lot more Subs than most people i think...100-200 on each Filter 180s to 300s ...so i have more to eliminate and keep the best possible..... Just my 2 cents ! |
1.91
#...
·
|
|---|
| I use blink with the individual stf applied and throw out subs where the main target (galaxies usually) becomes so faint that it almost disappears. (I also throw out subs with air plane trails or "fat" satellite trails.) Lighter subs are due to either high clouds, the moon, or approaching twilight. In my experience, such subs will show a higher median and lower star count in SFS, but also a higher SNR. The higher SNR is because if sky glow is strong enough, this is interpreted as signal, and SNR = median / sqrt(median). This is also the reason that I don't use simple SNR as a weight in image integration. |
5.21
#...
·
·
1
like
|
|---|
|
The only thing I use blink for is a basic crude evaluation of images the morning after so as to toss out the extremely useless and obvious bad frames. These are mostly environmental like fuzzy bright stars due to clouds or some kind of major guiding glitch like doubled stars or basic things like "the roof closed". I want to get rid of those right away because I know for sure I would never use them and do not want to include them in my totals since that affects what images I still need to take and I need to know that each night before I set up the night's run. Blink is a "quick and dirty" way to do that. 95% of my quality related rejection is done with subframe selector using a combination of FWHM and number of stars detected (more stars, lower FHWM). Finally a small percent more are inevitably rejected using Normalize Scale Gradient before combining. I rarely look at roundness since it is rarely a problem with my setups, but when I do I tend to toss out anything less than 85% round but anything that passes the FWHM and star count criteria are typically well above 90% round anyway. |
2.11
#...
·
·
7
likes
|
|---|
| Robert, I, personally, wouldn't be too quick to discard usable data. Blink's default stretch can accentuate the strength or weakness of a subframe. If we re-stretch using the bottom button, each frame gets a temporary stretch optimized for it alone. You might find that some of the lighter, lower contrast images are actually quite usable. My criteria is to keep any subframe that's in focus, well tracked, and devoid of major artifact (does not include satellite/asteroid trails as these are fine). So long as there's reasonable signal, let WBPP's measuring/weighting assign an appropriate, lesser contribution for the weaker ones. Thanks! |
0.00
#...
·
·
2
likes
|
|---|
Use subframe selector rather than blink. Blink is useful for basic preview. Its useless if you want to create high quality art. The subframe selector allows you to easily remove images that do not meet a certain criteria based on the values you enter, FWHM, Eccentricity, etc. I highly recommend watching a few youtube videos on using this process! Its awesome  |
0.00
#...
·
|
|---|
Robert Khoury: I have ran in to this as well. I started applying the automatic histogram to all images before I go through them. You just have to watch as some may be lighter due to light clouds. Additionally, not sure if you are doing this or not, but try to capture images that are just before or after the meridian. This cuts down ont he time for an image but you get better results when you are not down in the muck. I usually will shoot an object one to two hours before and after meridian. Then move on to the next. |
|
1.81
#...
·
|
|---|
| Thanks all, subframe selector is the way to go as I was definitely using Blink the wrong way. I'll add back my tossed Oiii data and run through subframe. Hopefully my Ha is sitting in the trash bin and salvageable. |
0.00
#...
·
|
|---|
|
I just look for clouds/ bad plane trails, and remove them. seems good enough to me. I get so little good time out anymore now I hate to waste any sub. |
2.41
#...
·
·
1
like
|
|---|
Robert Khoury: Hello Robert. The STF stretch is only for visualization purpose in the screen, do not affect really to image. In Blink window if you click on the upper button (Aply an automatic histogram...) all serie adjust its strectch to the selected image (for visualization purpose). If is not something exagerated, backgroud variatons will be compensated in ImageIntegration using Normalization=Additive with scaling. Regards. |
0.00
#...
·
|
|---|
| I'm still left wondering whether adding frames with a lighter background (no clouds etc) would negatively affect a stack? Like for example: 1) 5hrs exposure dark sky vs 2) 5hrs exposure dark sky + 5hrs exposure light polluted sky - which one would be better? |
|
2.41
#...
·
|
|---|
| It will probably make the final image worse, but it's hard to tell, it depends on how bright the sky is. Perhaps the best is to do a trial-error test. |
|
0.00
#...
·
·
1
like
|
|---|
Pepe Chambó: I'm rather hoping someone else has... I did a very basic experiment a few months back and the addition of frames taken under a brighter sky seemed to make little difference, although I thought perhaps it brought out the fainter features slightly more, while slightly worsening detail in the brighter regions - quite the opposite of what I expected... I'm not sure I would trust my findings though... |
