Hi Adam, Thank you for this valuable video. Not sure why the popup text when the mouse is over the High Sigma value shows "increase the value of this parameter to select more potential hot pixels"... I understand it your way: increase the value to select less hot pixels.
Confirmed... bad tooltip. It will be corrected in the next release. Thank you for letting me know. (I do think the way I explained it is correct... and it matches the original CC implementation.)
Yes yes, i also do believe you explained it the right way. What confuses me is the popup message when moving the mouse over the high sigma setting in wbpp
@@AdamBlock on various forums and facebook groups I feel the majority of people want to spend minimal effort in processing their photos. Heck they want to do minimal to take the photos such as not take dark or flat frames. Basically shoot, stack in deep sky stacker and auto stretch and post on facebook. I spent thousands on equipment, hundreds on software and thought why spend all of that only to have crap pictures to show for it. I paid for all of your videos and while Im not a master like you, I have greatly improved my abilities partly because I understand how the tools work now thanks to you! Also if you are reading this, I know you have a video on GHS but since seeing that Ive seen a few videos, even from the creators that show a different way to use it. I was hoping for a possible future Adam Block video showing that way too but from your perspective if possible. Thanks!
I’m wondering how this darkframe method performs when you have a sensor with a lot of amp glow. Wouldn’t you end up with a lot of “hot pixels” in the part of the frame where the amp glow manifests itself?
Excellent question. The answer is apparently just fine. The developers worked on precisely this situation and are proud of their results. I suspect the multi-scale treatment of the image does something to avoid amp glow being an issue. However, they have not shown the exact method/math.
Thanks for the update. I notice that when using the automatic cosmetic correction the file extension is simply c and not c-cc. This could be a bit confusing to some. Not a huge issue, but something to of which to be aware.
Interesting! I will need to look into this. I suspect the idea is that CC is now considered an option of the "calibration' process... It is now in ImageCalibration. I think this is the reason why. I will need to communicate this.
With my computer at least, the processing of hot-pixel detection is a non-issue, it only takes a few seconds. But is there a difference in accuracy between the two methods? Which method more accurately characterizes and identifies hot pixels? (I suppose this can be image dependent.) In an image of M31 I processed yesterday, I got the dark holes in star centers. This may be due to using the CC template method. I may have to switch back to taking dark frames. I stopped taking them when I couldn't detect any difference with my camera (ASI2600), but there may be an advantage to doing so here.
How sweet your last sentence is... As for "accuracy" ...the two methods are really different (as I explain)- hard to compare. Auto-detect is correlated with light frames. The other method uses dark frames only. SInce hot pixels are a feature darks (that can be calibrated in lights) there is a good argument for identifying them in dark frames only.
Since you mentioned it, it would be great to know any further thoughts you might have on the “dark frames are no longer needed with these new virtually-noiseless sensors” theory. I’ve been wary that something is missing in such an argument.
Well.. this is a perfect example of sensor characterization/calibration where once again darks are useful. I guess from a science/experimentalist point of view... you always calibrate your instruments. It is a measure of their performance. If you do not do this... you may not know how they may be changing/affected...etc.
For those still using an old school CCD with column defects it looks like one would need to stick to the old method where you can define the defect list in the CC template. This new method doesn't seem like it would catch column defects reliably. Have I got that right or am I being pessimistic?
There isn't a definitive answer to this question. It depends on the camera. For some sensors the hot pixel population may change on time scales you consider "short" and required updating. It is easy to test of course. Take some darks. Then a few months later do it again (same temperature and exposure times). Compare the darks... do the hot pixels change? Most will not...some will. How many? THis is how to know the answer to your question.
This was my first thought on watching Adam’s video. The other question that occurs (and I feel I ought to know the answer to this) is do hot pixels remain within the integrated master darks that most of us save in our darks library or are they removed in the course of their preparation? I’m guessing they do remain.
So, how would you apply this to Seestar S50 processing? I've just been using auto-detect and leaving Hot Sigma at the default of 3. I know it's only a Seestar, but I'm using it as my first platform to learn post processing. Thanks.
I am guessing you are getting calibrated frames out of his system. So this means yes, the auto-detect method is for you. If you get raw darks and lights- then you can use the new method.
Hi Adam,
Thank you for this valuable video.
Not sure why the popup text when the mouse is over the High Sigma value shows "increase the value of this parameter to select more potential hot pixels"...
I understand it your way: increase the value to select less hot pixels.
Confirmed... bad tooltip. It will be corrected in the next release. Thank you for letting me know. (I do think the way I explained it is correct... and it matches the original CC implementation.)
Confirmed... bad tooltip. My explanation is correct.
Yes yes, i also do believe you explained it the right way.
What confuses me is the popup message when moving the mouse over the high sigma setting in wbpp
@@stephanep1330 It is in error. It will be corrected in the next release.
It's about time! Nice :).
Awesome always excited for a new Adam Block video
Not enough people agree with you.. but thanks! lol
@@AdamBlock on various forums and facebook groups I feel the majority of people want to spend minimal effort in processing their photos. Heck they want to do minimal to take the photos such as not take dark or flat frames. Basically shoot, stack in deep sky stacker and auto stretch and post on facebook.
I spent thousands on equipment, hundreds on software and thought why spend all of that only to have crap pictures to show for it. I paid for all of your videos and while Im not a master like you, I have greatly improved my abilities partly because I understand how the tools work now thanks to you!
Also if you are reading this, I know you have a video on GHS but since seeing that Ive seen a few videos, even from the creators that show a different way to use it. I was hoping for a possible future Adam Block video showing that way too but from your perspective if possible.
Thanks!
@@thomasrider5852 Thanks for the kudos. So many videos to make... so little time! lol
Thanks for the video! I was wondering what 'automatic' was for and why Cosmetic Correction was greyed out.
Hi Adam, thank you for this update. Where we could find the 2DPlot script nowadays? 🙂
It is a Hartmutt Bornnemann Script: www.skypixels.at/HVB_Repository/
I’m wondering how this darkframe method performs when you have a sensor with a lot of amp glow. Wouldn’t you end up with a lot of “hot pixels” in the part of the frame where the amp glow manifests itself?
Excellent question. The answer is apparently just fine. The developers worked on precisely this situation and are proud of their results. I suspect the multi-scale treatment of the image does something to avoid amp glow being an issue. However, they have not shown the exact method/math.
Thanks for the update. I notice that when using the automatic cosmetic correction the file extension is simply c and not c-cc. This could be a bit confusing to some. Not a huge issue, but something to of which to be aware.
Interesting! I will need to look into this. I suspect the idea is that CC is now considered an option of the "calibration' process... It is now in ImageCalibration. I think this is the reason why. I will need to communicate this.
With my computer at least, the processing of hot-pixel detection is a non-issue, it only takes a few seconds. But is there a difference in accuracy between the two methods? Which method more accurately characterizes and identifies hot pixels? (I suppose this can be image dependent.)
In an image of M31 I processed yesterday, I got the dark holes in star centers. This may be due to using the CC template method. I may have to switch back to taking dark frames. I stopped taking them when I couldn't detect any difference with my camera (ASI2600), but there may be an advantage to doing so here.
How sweet your last sentence is... As for "accuracy" ...the two methods are really different (as I explain)- hard to compare. Auto-detect is correlated with light frames. The other method uses dark frames only. SInce hot pixels are a feature darks (that can be calibrated in lights) there is a good argument for identifying them in dark frames only.
Since you mentioned it, it would be great to know any further thoughts you might have on the “dark frames are no longer needed with these new virtually-noiseless sensors” theory. I’ve been wary that something is missing in such an argument.
Well.. this is a perfect example of sensor characterization/calibration where once again darks are useful. I guess from a science/experimentalist point of view... you always calibrate your instruments. It is a measure of their performance. If you do not do this... you may not know how they may be changing/affected...etc.
For those still using an old school CCD with column defects it looks like one would need to stick to the old method where you can define the defect list in the CC template. This new method doesn't seem like it would catch column defects reliably. Have I got that right or am I being pessimistic?
No... column defects are a different issue.
Adam, does this require the dark library to be updated more frequently for best results?
There isn't a definitive answer to this question. It depends on the camera. For some sensors the hot pixel population may change on time scales you consider "short" and required updating. It is easy to test of course. Take some darks. Then a few months later do it again (same temperature and exposure times). Compare the darks... do the hot pixels change? Most will not...some will. How many? THis is how to know the answer to your question.
Thank you.
This was my first thought on watching Adam’s video. The other question that occurs (and I feel I ought to know the answer to this) is do hot pixels remain within the integrated master darks that most of us save in our darks library or are they removed in the course of their preparation? I’m guessing they do remain.
@andrewj1132 yes, I would agree with that.
@@andrewj1132 Yes... the hot pixels are in each raw dark. They are semi-stable over long periods of time.
So, how would you apply this to Seestar S50 processing? I've just been using auto-detect and leaving Hot Sigma at the default of 3. I know it's only a Seestar, but I'm using it as my first platform to learn post processing. Thanks.
I am guessing you are getting calibrated frames out of his system. So this means yes, the auto-detect method is for you. If you get raw darks and lights- then you can use the new method.