GreatAttractor

On Sunday the seeing was finally good enough to utilize my RC8 + LS50THa + Aried tri-band ERF setup. One of the best videos yielded this image of AR 2822:

I continued recording for some time, even though the seeing was variable and a high thin cloud was passing. I saw a few bright points appear, but had no way of knowing it would be a nice C4.0-class flare, until I put together an animation (20-second intervals, 43 minutes total):

Beside the "igniting grass", note how there's a brightening in the billowing "smoke", right before a thin stream gets sucked back in to the smaller sunspot.

I'm really satisfied; even despite the so-so seeing this tiny thing looks very interesting. Can't wait for an M-class like the one I caught with 90 mm – it would fill the whole FOV with twisting and churning plasma!

I also recorded a CaK animation (Lunt CaK module, 90 mm refractor, PowerMate 2.5x), much better seeing than during the previous attempt, with consistently good resulting frames, but nothing happened there at all:

Mandatory full disc from Lunt 50:

and prominences from the 90 mm refractor:

Captured with PGR Chameleon3 mono (ICX445), processed with AviStack 2, Stackistry, ImPPG, GIMP.

Nice catch!

Just a side note, I've just checked a 400-kilobyte JPG (quality = 90) would be fine without any loss of image details, instead of a >10-megabyte TIF

On 24/04/2021 at 09:47, Aetherum said:

I can't use autostakkert natively as I only run on Linux and Mac systems ImPPG likewise)

I know that people use the Windows build of ImPPG successfully on Mac via Wine. As for Linux, it's straightforward to build from sources (I develop and use it on Fedora) - let me know if you try and if there are any problems.

I had a nice, sunny Sunday with good-to-average seeing.
 
Best frames, showing active regions 2018 and 2020:
 

 
Not much was happening in these ARs during this capture (30 s intervals, 1:32 h total):
 

 
(I checked in the NOAA solar event list that there was actually a small B-class flare in one of the other ARs.)
 
I started in the morning with the big prominence, it was calm enough back then (30 s intervals, 1:00 h total):
 

 
...but a few hours later (I think it was the same one - it appears this way in the GONG archive) it became a bit more lively (same speed, 1:04 h total):
 

 
Active regions in white light (30 s intervals, 0:34 h):
 

 
A bit disappointing, I was counting on more pore movement, like in this animation from a few years back.
 
And finally — my first CaK animation (30 s intervals, 0:58 h total):
 

 
Interesting little sparks in the lower sunspot, but according to NOAA there were no flares there at the time.
 
 
 
Everything captured with PGR Chameleon 3 mono (ICX445), processed with Stackistry, AviStack 2, ImPPG & GIMP.
 
Hα: 90/660 mm refractor + Lunt 50 etalon, Barlow 1.6x.
CaK: 90/660 mm refractor + Lunt CaK B600 module, PowerMate 2.5x.
WL: SW Mak 127, Baader Astrosolar ND 3.8 + Solar Continuum filter.

A new version of ImPPG has been released.

Home page: https://greatattractor.github.io/imppg/

Download from: https://github.com/GreatAttractor/imppg/releases/tag/v0.6.3

Enhancements:
  - Opening an image file by dragging and dropping onto the ImPPG window

Bug fixes:
  - Crash when batch processing in CPU mode with deringing enabled

That's an interesting paper. If I understand correctly, NAFE is a sort of histogram stretch, performed piecewise for each image fragment.

19 hours ago, Kitsunegari said:

Tried it out on one of my old calcium timelapse to see waht happens and it turned out a bit wonkey.  Surface looks like foam

The example in the paper's Figure 2 looks similar to your result - i.e., dark, low contrast areas are "super-charged", stretched locally to cover a much wider brightness range. Certainly useful for a detailed analysis of small structures, but by definition it won't look like the raw image.

From the paper:

Quote

The program NAFE Image Analyzer, for MS Windows XP and later versions written in Borland Delphi, was developed to implement the NAFE method.¹ As the NAFE method is extremely time consuming, parallel implementation was necessary. Processing of a full (4, 096 × 4, 096 pixels) SDO AIA image takes approximately 5.5 minutes on a PC with Intel Core i7-3820 working on 3.6 GHz (8 processor kernels).

Sounds like a great candidate for porting to GPU!

Dave, the original article (with all derivations) can be found here: http://adsabs.harvard.edu/full/1993SoPh..145..389S

I tried to figure out the 4.46 value in this post and I think it checks out.

Really great animations. Can you remind us what telescope was used?

Good catch!

You can check for flares in the solar event lists published by NOAA here: ftp://ftp.swpc.noaa.gov/pub/indices/events/

The README file explains the notation used. For instance, on 10/18 there were several B-class flares:

:Product: 20201018events.txt
:Created: 2020 Oct 21 0357 UT
:Date: 2020 10 18
# Prepared by the U.S. Dept. of Commerce, NOAA, Space Weather Prediction Center
# Please send comments and suggestions to SWPC.Webmaster@noaa.gov 
#
# Missing data: ////
# Updated every 5 minutes.
#                            Edited Events for 2020 Oct 18
#
#Event    Begin    Max       End  Obs  Q  Type  Loc/Frq   Particulars       Reg#
#-------------------------------------------------------------------------------

7010 +     0204   ////      0204  LEA  U   RSP  025-030   III/1                 

7020 +     0243   0244      0244  LEA  G   RBR  245       100                   

7030       0248   0252      0256  G16  5   XRA  1-8A      B1.8    5.9E-05   2776
7030 +     0250   ////      0251  PAL  C   RSP  120-180   III/1             2776
7030       0251   0251      0251  LEA  G   RBR  245       110               2776
7030       0254   0254      0300  LEA  3   FLA  S15E22    SF                2776

7050       0314   ////      0354  PAL  C   RSP  025-038   III/1                 

7060       0551   0558      0604  G16  5   XRA  1-8A      B1.0    6.4E-05       

7070 +     0852   ////      0857  SVI  C   RSP  065-080   III/1                 

7080       1313   1321      1326  G16  5   XRA  1-8A      B1.0    6.8E-05       

7090       1420   1429      1437  G16  5   XRA  1-8A      B4.0    2.6E-04   2776
7090 +     1424   1427      1443  HOL  3   FLA  S14E16    SF                2776

7100 +     1612   1642      1654  HOL  3   FLA  S22W71    SF                2777
7100       1626   1636      1643  G16  5   XRA  1-8A      B1.7    1.1E-04   2777
7100       1633   ////      1634  SAG  C   RSP  049-180   III/1             2777

7110       1658   1700      1737  HOL  3   FLA  S22W72    SF                2777

7120       1738   1745      1833  HOL  3   FLA  S22W72    SF                2777

7130       1834   1853      1900  HOL  3   FLA  S22W75    SF                2777
7130       1836   1842      1851  G16  5   XRA  1-8A      B1.2    1.0E-04   2777

7140       2004   2004      2010  HOL  3   FLA  S23W76    SF                2777

We're interested in XRA (X-ray event) and FLA (flare visible optically in Hα; I guess a FLA will usually have a corresponding XRA). Check your recording time to find out which was yours.

It's new, I had a look and the mini-ERFs look all nice and shiny for now. Good to know about possible replacement, thank you. I'll keep it in mind about usage with Aries ERF.

I'm learning how to use my newly acquired Lunt CaK module (straight-through, B600). Unfortunately there was literally nothing on the Sun at the time of capture, but the image quality seems promising (all from 90/660 mm achro, PGR Chameleon 3 mono/ICX445, AviStack 2, ImPPG):

SW Barlow 2x:

PowerMate 2.5x:

I got my GSO RC8 mainly for solar work, but it's promising also for planets. I had a spell of good seeing yesterday:

23 minutes, 3-minute intervals, PGR Chameleon 3 mono (ICX445) + Baader Red 610 nm long-pass filter, f/16, resized to 150%, AviStack 2 + ImPPG. It seems I have to tweak the collimation some more (the "limb rind" artifact should be symmetric, and not more prominent lower in the image).

The small bulge in the upper right is Olympus Mons.

Excellent animation.

At this scale I'd suggest shorter intervals for smoother motion. E.g., I used 30 seconds here (15-second videos with 15-second breaks):

3 hours ago, assouptro said:

I did! 
what an epic task!!

Indeed. One gets better at it with time, I got down to maybe 3-5 s per image (using transparent layers in GIMP); but still, those 200-frame time lapses were tiring. So I wrote a tool to automate it, give it a try: ImPPG

TL;DR version: download the program, choose Tools/Align image sequence... from the menu and enjoy the frames aligned with sub-pixel precision.

The batch processing function may be also of interest; check the tutorials linked on the homepage.

Great job!

Did you align the frames manually?

9 minutes ago, David Smith said:

Yep, me too.

And me, in Firefox and Chrome.

Could you upload as an animated GIF?

53 minutes ago, Kitsunegari said:

They are also display very bad image compression which degrades the image big time

This sounds like color-reduction side effects (GIF uses lossless compression, so compression artifacts like in e.g. JPG are in fact not possible). Make sure to select Image/Mode/Grayscale before exporting.

53 minutes ago, Kitsunegari said:

 I did not see an mass saving feature in Gimp  and each one needed saving individually which took a very long time.   Do you know a trick to do a batch process?  That would help me out a ton!

Right, you cannot save the layers individually with one command. In my workflow, though, it's not needed: I "open as layers" to load all frames, crop and/or resize, check the animation using Filters/Animation/Playback..., and then export straight to an animated GIF.

Excellent! To me it's the best thing to image on the Sun: a boiling, spiking active region  right on the limb. Good to know it can look spectacular also in CaK.

Don't forget to try the mass cropping of your frames in GIMP.

Good to know about the required cadence for CaK time lapses. I've been very satisfied with my older Chameleon3 (up to 30 fps at full frame, perfectly fine for Hα and WL), but now I'm reconsidering getting a newer, faster CMOS model.

Based on these newer images I agree, all the lines are really coming from underlying data. As you wrote, they should not be oversharpened (then they look unreal, too thin and too uniform in brightness for the aperture used).

And the animation rocks! (I like the "one pass" version better.)

1 hour ago, Kitsunegari said:

I am just trying to figure out why Valery's and Dutch open telescope and several other users are getting the similar effect;  are we all processing wrong?

No, the bright "celullar" pattern of lines is there for real. It's just that it gets "overcooked" when you keep applying deconvolution over and over.  E.g., those super-fine bright lines in your 7th pass don't look like something that could come out of 127 mm aperture with the kind of PSF it has - but rather like accumulated ringing artifacts.  (Note how in Valery's and DOT images the lines are randomly oriented, but the 7th pass shows them mostly near-vertical and near-horizontal.)

Of course, I can't be sure where exactly "overcooking" begins - one would have to, I guess, capture at the same time and conditions also with a large aperture and compare the results.

I have no experience with CaK imaging and processing yet, but your 4th pass and above definitely look "overcooked" (with "ringing" artifacts of sharpening).

It's a good idea to compare to DOT images (maybe also the 1-meter Swedish Solar Telescope has some CaK material in its gallery). Another thing you could try is running the raw video through Stackistry and checking the mosaic of best fragments it generates. (In case of white light material, it would nicely show granulation in the whole FOV.) This gives some idea about how the "real image" would look without seeing effects (though it will be noisy and low-contrast, so a histogram stretch will be needed - can be done in ImPPG, just disable all sharpening and use the "stretch" button in the curve window).

(See the tutorial on how to get this best fragment mosaic; make sure to enable subtitles. You don't need to wait for stacking to finish, the mosaic is available as soon as "Quality Estimation" finishes.)

Thanks to Rusłan there are now Russian and Ukrainian translations:

Version 0.6.2 can be downloaded from: https://github.com/G.../imppg/releases

Hi David, Stackistry is not a mature tool yet, though it usually works fine for solar Hα material (that's how I use it).

Another open-source stacker has been recently announced, could be of interest: PlanetarySystemStacker.