When come the lines?

No, it's not really in any of the subs other than as some nascent data the CC brings forward. The series above shows it in a single sub, and no matter how I set CC to basically say "do nothing" it still appears, and it's in the real time preview as well whether or not the change is on, i.e. CC's preview shows it even when "off". Which is bizarre.

Thinking it might be the bit-ness of the preview, which I think is low, I changed to something else (curves, with no curve) and it looks just fine.

I think the next thing to do is wipe the intermediate files and run without CC at all. But first going to eat dinner and then take a fresh look, as this is just too bizarre, I must be doing something wrong.

If anyone wants to take a run at this, here's a zip file with the calibrated sub, and the cosmetically corrected sub. This structure I have been highlighting is at 4884, 3092 (pixels), you need to really reduce the auto-STF to see the stars.

https://drive.google.com/file/d/17lUtcaGM53afSVv9Kx2Kx9MPBq2g5v6_/view?usp=sharing

I'm starting to think the real answer is to stop pixel peeping.
 
Last edited:
I'd like to see that single calibrated frame run with CC but without cold correction. I can (sort of) imagine a gap between two bright stars where the brightness is much lower than the median of the (mostly bright star) neighbours, triggering a "cold pixel" correction to the surrounding median value.
 
... that would then predict that this would only be seen on crowded fields of bright stars, and only when running CC with cold correction (which I must admit I never even thought of enabling).
 
I think it still shows up, but there's the calibrated frame if you want to give it a go. I think that whatever CC does, regardless of settings, it is highlighting this wall in some fashion (and anyone just reading the end -- that's an example, the linear artifacts are all over the core). Drizzle integration especially with variable kernel highlight it further, as does any of BX, LHE, or HDRMT.

I'm betting when this finishes running (might be morning) that they will not be there, or nearly not there, without CC (that's the only change I made).
 
I saw it had the right time stamp and the file name was longer (it was in my _c folder), I forgot I ran it twice. Sigh...

Here is a corrected zip file. This is a different calibrated sub, as I wiped everything to rerun, but it should be identical since nothing else changed but removal of the _CC (in retrospect I should have left the calibrated folder alone but didn't).

https://drive.google.com/file/d/1KbdNH9fB22zMPKNB6-_ffkEElgfhLKaM/view?usp=sharing

Apologies for the screwup. But this is what worries me about the whole issue, that I am doing something stupid and cannot see it myself. So hopefully you can.
 
OK, the effect is definitely caused by running CC with cold correction. The dimmer gaps between the packed stars are typically brightened, resulting in an entirely synthetic "bright haze" background, and when the spacing is right, the bright lines appear. None of this happens running CC with hot correction only (the way I have always run it).
Bottom line: CC with cold correction is not a good choice for globular clusters.
 
When this run finishes without any, I'll experiment again. I just rebuilt my dark library so I suspect CC was not having much positive effect. I could start a new instance but have found it is best to just let PI do its thing alone, it seems happier and barf as often. It's just starting Blue integration.
 
OK, integration worked, and there's a significant difference. I want to run some CC's separately to see the cold vs hot, etc. but I though tthese might be interesting. This is a drizzled integration of the same frame showing the CC and non-CC versions fresh out of integration. It's an animated GIF, hopefully it will show up. Notice in particular right side just below the middle and maybe 10% in from the edge.

drizzle.gif


To illustrate how this changes look how badly BX emphasizes them. I am not saying this is about BX or that this is a good BX run on the non-CC one, I am just offering it as a way to emphasize the differences in the CC and non-CC. The same BX was run on both the CC and non-CC drizzle.

NoCCBx.gif


Now off to do some CC runs alone and see if I can understand. Thank you Fred for hanging in there to try it. And I think your conclusion is right, "Doctor it hurts when I run CC on Globular Clusters". Answer: "Don't do that".
 
And yes, experimentation shows it is only (and always) cold.

And interestingly even if you set the slider for cold to zero, it does it.
 
Thank you all, I am very glad to have found this. My core of M5 is looking MUCH better. It's nothing special I know, but it no longer looks like an Alien megastructure.

core.jpg
 
And interestingly even if you set the slider for cold to zero, it does it.
Expected result. The correction is applied to pixels that exceed the selected number of sigmas, so setting 0 applies the correction to the whole image - which is effectively applying a localised median filter. The bigger the number of sigmas, the less the number of pixels detected.
 
Expected result. The correction is applied to pixels that exceed the selected number of sigmas, so setting 0 applies the correction to the whole image - which is effectively applying a localised median filter. The bigger the number of sigmas, the less the number of pixels detected.
Wow. I just want to point out that this is all @robyx's fault with WBPP. There was a time when I was doing these by hand that I knew such things, and paid attention to how each step worked. Now it's just gone from my brain. Vanished, the space reclaimed and used to store Netflix movies or some such.

Thanks for the patience @fredvanner.
 
A final note for folks just scanning through the thread:
The problem is not with CC; running CC with hot pixel detection is still a good strategy for all images.
The problem is running CC with cold pixel detection; while this could in principal correct dead pixels in a single frame, the artefact vulnerability revealed in this thread suggests that this option is best avoided. Dead / cold pixels will be corrected by integration with dither. CC of hot pixels can prevent registration problems (with hot pixels mistaken as stars), but there is no corresponding vulnerability to dead (cold) pixels.
 
A final note for folks just scanning through the thread:
The problem is not with CC; running CC with hot pixel detection is still a good strategy for all images.
The problem is running CC with cold pixel detection; while this could in principal correct dead pixels in a single frame, the artefact vulnerability revealed in this thread suggests that this option is best avoided. Dead / cold pixels will be corrected by integration with dither. CC of hot pixels can prevent registration problems (with hot pixels mistaken as stars), but there is no corresponding vulnerability to dead (cold) pixels.
I wouldn't say "avoided". I'd say "used with caution, and an understanding of the process". I've been going back and processing images I took 20 years ago, with very different equipment (and processed originally with much less capable tools). The data are the data, already taken. As they are. And that camera had dead pixels, and they survive through PI processing if they aren't explicitly removed during preprocessing... where CC works perfectly on them.
 
Back
Top