As you can see, I had been working with MLAstro for quite some time already, but I didn’t own the instrument. This has recently been "fixed" and I’m now a happy user of the SHG 700!

I must say that Minh’s design is fairly impressive, it’s a truly qualitative instrument. The aluminum housing makes it extremely robust, without any flexion, and it comes pre-collimated. In addition, the micro-focusers, which are used for the collimator lens, for the camera objective and for the wavelength selection wheel, are extremely pleasant to use: anyone who has struggled with the collimation of the Sol’Ex will immediately feel the magic.

Being a regular user of the Sol’Ex, I immediately felt comfortable with the SHG 700: it only took me a few minutes to setup and get my first images! Fine tuning the focus is a breeze with the microfocusers, it’s really fantastic to use.

My first images were showcased by MLAStro, but here are a few:

While the above images were fairly easy to produce, I was puzzled because I didn’t manage to get any decent image in Helium D3. This was surprising, because the sensitivity of the SHG700 is higher, especially because there’s no need for a ND filter or a an ERF, so it was curious that the only helium image I was able to produce was this:

To understand the problem was that, it is important to mention that unlike Minh, I was using JSol’Ex one-click, fully automated processing, a feature which was introduced a while ago (June 2024) and worked extremely well for both Sol’Ex and Sunscan files (N.B: the Sunscan app introduced the same feature a few days ago).

This feature only works if we can properly compute the dispersion of the spectrum, which is measured in Angstrom/pixel. In order to compute this, we need to know the specifications of the spectroheliograph, such as the grating density, the focal length of the collimator and objective lenses, the total angle as well as the pixel size of the camera. Once we know all this, we can determine how many pixels separate the reference line that we use, for example the Sodium D2 line, from the Helium D3 line. To illustrate this, let’s say that we have a dispersion of 0.1Å/px. The Helium line is to be found at 5875.62Å, when the reference line, the Sodium D2 line, is detected at 5889.95Å. Therefore, the Helium line can be found 14.33Å away from the D2 line, which means 14.33/0.1 = 143.3 pixels away.

Using both Sol’Ex and Sunscan, I had great experience at extracting this line automatically, so it was to say the least curious that it wouldn’t work with the SHG 700.

So I contacted Minh, and after eliminating obvious possible candidates, like weak signal or incorrect exposition or gain, I decided to go the "old way" and searched for the helium line manually. It was with great surprise that I discovered that when JSol’Ex told me that the line should be 124.9, I was measuring something closer to 116 pixels! I brought this to Minh, and we identified 3 possible causes for this:

It was also possible, but unlikely, that a combination of 2 and 3 would happen. The first thing I’ve done is double checking my formula to compute the dispersion in JSol’Ex. I was doubtful that it could be wrong, given that it was used with success on different SHGs. In addition, it gave exactly the same result as the Ken Harrison' SimSpec SHG spreadsheet.

So we moved to the 2d option: the SHG 700 was advertised with a focal length of 75mm. However, the pixel shift I was manually measuring was closer to 70mm. I brought this again to Minh, who contacted the supplier of the lens, and here’s what he told me:

So I changed the focal length to 72mm and got this image instead:

and a stack of 5 images processed entirely in JSol’Ex:

That’s quite a difference! So it appeared that the software was correct, and that it allowed identifying a problem in the spectrograph specifications, because a spectral line wasn’t found where it should have been! While going from 75mm to 72mm won’t make much of a difference, the fact of not using the right numbers makes a huge difference in JSol’Ex: computations are all off, which includes the pixel shifts like in this exercise, but also the measured redshifts. In addition, this would make it impossible to perform more complicated tasks like finding the ionized Fe lines when imaging the corona E. The image is stil less contrasted than it should be, which may indicate that the computation is slightly off, or it’s just due to the weather conditions that day, I didn’t have the opportunity to retry.

Lastly, we can actually see fairly easily that the new focal length is a better fit, by using JSol’Ex "profile" tab. In that tab, we compare the profile of the spectrum that you captured with a reference spectrum from the BASS2000 database: this is also how the software automatically determines what spectral line is observed, by comparing the profiles together.

With a 75mm length and an H-alpha profile, here’s what we got:

You can see that while the H-alpha profile is found, as soon as we move towards the wings, there are slight shifts between the local minimas. When we switch to a 72mm length, these are perfectly aligned:

The SHG 700 is a fairly impressive instrument: it’s robust, it’s a pleasure to use with its microfocusers, and Minh is always super responsive and very patient. Its use doesn’t come without drawbacks, though. It’s weight, for example, restricts it to refractors which have a good focuser. The dimension of the sun is also smaller than with the Sol’Ex at equivalent focal length (see this post for an explanation). However, it produces stunning images, sometimes rivalizing these produced with an etalon.

While testing it, I faced this problem that the helium line images were significantly worse than with the Sol’Ex, which didn’t quite make sense. After investigation, it turned out we had highlighted a difference in the specifications, a lens had been changed from 75mm to 72mm by the supplier, without letting MLAstro know. That’s a pity, but, in the end, the problem is very easy to fix in JSol’Ex. Be sure to upgrade to JSol’Ex 2.11.2 which includes a fix to update the focal length.

First of all, a bit of vocabulary. An active region is a region of the Sun atmosphere where special activity occurs, such as flares or coronal mass ejections. They don’t have to be associated with sunspots, but in general, they are. In JSol’Ex, we’re essentially detecting sunspots, and the terminology "active regions" essentially comes from the fact that we can use the https://www.swpc.noaa.gov/NOAA database] to label these active regions.

An instrument like Christian Buil’s Sol’Ex, called a spectroheliograph (or SHG in short) doesn’t offer any kind of "live view" like typical solar instruments like Coronado or Lunt instruments. Instead, what we get is a video file, where each frames consists of a "slice" of the sun, observed as a portion of the light spectrum:

The video above is an excerpt from a so-called "scan": the principle is to have a slice of the sun passing through a slit, and a grating is used to spread the light into a spectrum. Here, we are observing a curved dark line, which is the H-alpha line, and the "wobbling" we see around that line is an illustration of the Doppler effect. The idea of software like Valérie Desnoux’s INTI and JSol’Ex is to extract pixels from the studied line (here H-alpha) in order to reconstruct an image of the sun.

However, as you can see in that animation, there’s a lot more information available in each frame. While we are mostly interested in the central line (here H-alpha), it’s also interesting to look "above" or "below" the line, which is often referred to "pixel shifting", in which case we’re not studying H-alpha, but a different wavelength: that’s one of the strenghts of Sol’Ex, which makes it possible to do "science" at home!

In particular, this video shows a couple interesting features:

This video is actually an excerpt from one of the many captures I’ve done with Sol’Ex, and I captured it during an eruption, on May 5th, 2024. What you are seeing here is the massive AR3664 region which was suject to multiple X-flares and resulted in beautiful auroras on Earth!

I’ve always considered that it would be a cool feature to be able to detect these lines automatically in JSol’Ex, and provide an overlay of the detected sunspots. Here we go, it is finally implemented in JSol’Ex 2.9.0! If you select the "full processing mode" or that you check the "active regions" checkbox in a custom process, then JSol’Ex will automatically create an image of the sun with the detected active regions as an overlay:

Unfortunately that day I didn’t capture a full disk, but you can see that JSol’Ex annotated the disk with the detected active regions, but it also added the labels for these regions automatically.

Let’s take another example with an image captured in Calcium K on January 17, 2025:

You will notice 2 different colors for labels:

Sometimes, you will see like in the image above regions which are not detected, and others which are detected but not in the NOAA database. The reason why not all of them are detected is that I had to choose "reasonable" detection thresholds, which work for most use cases. I plan to improve the algorithm over time to make it more robust, based on your feedback.

The algorithm is based on a simple analysis of each frame. If you open your SER file in JSol’Ex video analyzer, you will see something similar to this:

On the top, you see the original frame, with the curved H-alpha line. On the bottom, you see the corrected frame, where the H-alpha line is straightened, and the active regions are highlighted in purple.

The algorithm is based on the following steps:

For each frame:

The reason to only keep candidates which have both average intensity and standard deviation below a threshold is because:

At the moment, I’m using the following thresholds (note that they may change in future releases, as I improve the accuracy):

Once we have the results for all frames, we aggregate active regions by collecting adjacent candidates.

Finally, we filter out regions which are too small, then perform clustering of regions which are close to each other.

The whole algorithm can be found here (note that it also includes redshift detection, which was discussed in a different blog post).

This algorithm proves to work relatively well in many different wavelengths (H-alpha, calcium, magnesium …​). However, there are sometimes false positives. This is for example the case when I’m scanning in H-beta, due to the long focal length of my telescope and astigmatism, and the fact that H-beta provides a lot of details.

In this case, the algorithm detects areas which are actually just noise:

Note that these are close to the north and south poles. I have also noticed that the algorithm tends to detect noise as active regions when we’re close to the limb, which is also why I’m currently filtering these out.

At this stage, I have chosen not to make the detection thresholds configurable, because I consider these internal implementation details, which may change in the future, and that I don’t want to expose to the user.

Once piece of work that we didn’t explain yet is how JSol’Ex puts labels around active regions. For this, we are using the NOAA Solar Region Summary database.

This provides us, at a particular date, the list of active regions with their positions on the solar disk. JSol’Ex will compare these with the detected regions, and put the labels in different colors based on whether they were detected or not.

However, the position of active regions will only be correct if:

The data from NOAA is cached in your local filesystem, so that we don’t have to download it every time you open a video file.

Despite only having released this a day ago, I already have received the same question multiple times: can JSol’Ex be used to annotate an existing image of the sun, that is to say, take a JPG or PNG image and annotate it?

If you have read carefully this blog post and that I explained things correctly, you will have understood that the answer is no: because my algorithm is based on the analysis of each frame, there’s no such information available in a single image.

I hope you will enjoy this new feature in JSol’Ex 2.9.0. This blog post is a tentative explanation of the algorithm, and I will be happy to answer any questions you may have about it. As always, feel free to contribute, JSol’Ex is open source!

Rappelons tout d’abord le principe de base du Sol’Ex de Christian Buil. Le concept requiert de reconstituer une image du soleil, ligne par ligne, en exploitant une vidéo dont chaque trame montre une partie du spectre solaire, centré sur une raie particulière que l’on étudie. La raie la plus communément étudiée est la raie H-alpha, qui, sur le spectre solaire, apparaît en absorption, c’est à dire qu’elle sera une ligne sombre sur une image du spectre :

En haut, l’image telle qu’on la trouve dans la vidéo, la ligne est "déformée". En bas, l’image "corrigée". Les points bleus correspondent à la détection de l’effet Doppler, les lignes sombres verticales correspondent à des taches solaires.

Les logiciels comme INTI et JSol’Ex exploitent le fait que la ligne étudiée est la plus sombre de l’image pour se repérer. Un des aspects fondamentaux de la reconstruction que je n’avais honnêtement pas compris lorsque je me suis lancé dans ce projet, c’est que tout le signal permettant de recomposer l’image H-alpha se trouve dans cette ligne sombre. En effet, même si elle paraît "noire", il y a en fait bien d’infimes variations dans cette ligne, et c’est celà qui nous sert à reconstituer une image !

La détection de raies sombres permet, si la fenêtre de cropping du spectre est relativement petite, de se concentrer sur une raie à étudier. Ca fonctionne très bien pour les raies H-alpha, Magnésium, Calcium K ou H, etc, qui sont des raies en absorption.

En revanche, la raie Hélium est une raie en émission : elle est "claire" au lieu d’être sombre, mais elle est aussi impossible à distinguer dans la plupart des trames parce que noyée dans le flux. Aussi les logiciels ne peuvent pas la trouver.

Alors, comment fait JSol’Ex, dans ses dernières versions, pour être capable de produire en 1 clic une image Hélium comme celle ci-dessous ? La question est intéressante non seulement d’un point de vue technique, mais aussi pour comprendre la façon dont j’aborde le développement de JSol’Ex.

Le site de Christian Buil est une nouvelle mine d’information pour nous aider : pour pouvoir produire une telle image, il est nécessaire de prendre une raie sombre comme référence, puis d’appliquer un "décalage de pixels" pour "trouver" la raie Hélium. Enfin, il est nécessaire de procéder à une soustraction du continuum (une 2ème image).

Cette notion de décalage de pixels est bien connue des utilisateurs chevronnés du Sol’Ex. Le principe est relativement simple : au lieu de reconstituer une image en utilisant le centre de la raie détectée (la ligne rouge dans l’image spectrale ci-dessus), on va reconstituer une image en se décalant vers le haut ou vers le bas de quelques pixels. C’est ce même principe qui permet de créer des images Doppler du soleil, qui montrent en bleu les régions qui s’approchent de nous et en rouge celles qui s’éloignent. On peut même produire des timelapses assez spectaculaires comme cette animation que j’ai réalisée le 5 juin 2024 et qui est générée par le logiciel en quelques minutes :

Comme Christian l’explique dans cette vidéo, trouver ce décalage de pixels n’est pas forcément chose simple. Tout d’abord, il est nécessaire de trouver la raie "sombre" de référence : on utilisera traditionellement le doublet du sodium pour se répérer, puis on utilisera la raie Sodium D2 ou encore la raie Fe I présente à côté comme référence.

Ensuite, il faut trouver ce fameux décalage de pixels pour "tomber" sur la raie Hélium. La vidéo de Christian ne montre pas les dernières améliorations que Valérie Desnoux a intégré à INTI pour rendre les choses plus simples, mais, grossièrement, il faut :

Cette procédure, bien que documentée, est très intimidante pour les utilisateurs et explique que peu se soient lancés dans ce défi.

Dans JSol’Ex, la procédure est simplifiée au maximum :

Ca ne prend que quelques secondes !

Dans ce billet, j’ai décris la façon dont je procède pour améliorer JSol’Ex. En premier lieu, il s’agit d’identifier un besoin particulier, par exemple, ici, produire une image Hélium. A partir de ce besoin, il s’agit de chercher comment simplifier un tel traitement. La simplification ne se fait alors qu’à partir de ce dont je dispose à un instant t. Par exemple, dans un premier temps, il a s’agit d’ajouter un système de scripts, qui, outre le traitement des images Hélium, permet d’exploiter la richesse des données disponibles dans un scan. Les personnes intéressées peuvent en apprendre plus sur les scripts dans ce tutoriel.

Ensuite, il a s’agit d’ajouter des fonctionnalités permettant de simplifier la configuration pour les utilisateurs, en l’occurrence la détection automatique de raie, puis d’exploiter ces nouvelles fonctionnalités pour simplifier encore plus le traitement des images.

Ainsi, il s’agit d’une méthode très itérative, mais toujours dans le but de livrer des incréments fournissant une certaine valeur ajoutée aux utilisateurs. La bonne nouvelle, c’est que j’ai beaucoup d’autres idées en tête !

CLAHE est un algorithme qui améliore sensiblement le contraste. Cependant, je n’ai jamais été très content du résultat. Je ne sais pas comment Valérie Desnoux fait dans INTI, qui a l’air de s’en sortir mieux, mais dans JSol’Ex les résultats obtenus sont assez moyens. En particulier, je note plusieurs défauts :

Pour illustrer mon propos, voici par exemple un disque solaire (le fichier SER est celui disponible sur le site de Christian Buil) traité par JSol’Ex 2.1 (version précédente donc), avec les paramètres par défaut, une tuile de taille 16 pixels (à gauche) ou 64 pixels (à droite) :

On note déja clairement éclaircissement des limbes, et des artéfacts "carrés" qui apparaissent dès que la taille des tuiles augmente. Trouver les bons paramètres qui conviennent à tous étant compliqué, JSol’Ex offrait déja la possibilité de changer ces paramètres (taille de tuile, intensité, …​) mais je pense que peu d’utilisateurs le faisaient.

Aussi ais-je décidé d’ajouter un algorithme dans JSol’Ex 2.2 dédié aux images solaires. Pour vous donner un peu envie de lire la suite, voici ce qu’on peut obtenir avec JSol’Ex 2.2 sur la même image :

Le nouvel algorithme est disponible dans JSol’Ex 2.2 et est l’algorithme utilisé par défaut. Il combine plusieurs techniques, dont une correction du gamma avec masques, CLAHE et un stretching dynamique de l’image, pour produire une image plus digne de ce que Sol’Ex peut faire. Je ne prétends pas que cet algorithme est parfait, il a lui aussi des défauts, mais il semble être un bon compromis.

Afin de vérifier mes assertions, j’ai procédé méthodiquement à une comparaison des images produites avec les paramètres par défaut de INTI, JSol’Ex 2.1 et JSol’Ex 2.2 (la seule modification est l’autocrop activé et un retournement vertical pour que les images soient orientées de la même façon).

Commençons par la vidéo H-alpha de démonstration utilisée par Christian Buil sur son site.

Les images pouvant être difficiles à comparer en taille réduite, je vous invite à faire un clic doit et ouvrir l’image dans un nouvel onglet pour comparer.

On note clairement que sur JSol’Ex 2.1, il y avait certes une amélioration de contraste, mais elle se faisait au prix d’artéfacts et d’une perte de relief. En revanche, JSol’Ex 2.2 offre une image plus nette que celle d’INTI, sans avoir les défauts de CLAHE.

Continuons avec une autre image solaire en H-alpha, avec plus de dynamique :

Là encore on remarque que JSol’Ex 2.1 produisait une image raisonnable mais assez saturée et surtout "plate". La version 2.2.0, quant à elle, offre une meilleure dynamique tout en préservant les détails et cette impression de profondeur.

Nous pouvons aussi comparer les résultats sur une image obtenue avec une plus longue focale et un disque partiel :

Cette fois-ci on note que les 3 logiciels s’en tirent honorablement. Cependant, JSol’Ex 2.1.3 affiche une image moins contrastée que la v2.2.0, alors qu’INTI v6 affiche une image légèrement plus floue.

Malheureusement suite à une fausse manipulation, j’ai perdu la plupart de mes fichiers SER en raie calcium. J’ai cependant pu faire des comparaisons, sur des fichiers loins d’être idéaux. Les résultats sont cependant intéressants :

Cette fois-ci, on constate que JSol’Ex 2.1 s’en sortait plutôt bien. INTI là encore fait un travail remarquable, mais JSol’Ex 2.2 sature trop l’image. C’est un défaut que j’espère arriver à corriger, qui est lié au fait que les images calcium on un histogramme avec une gaussienne à base très large. Il est néanmoins possible d’atténuer la saturation en choisissant un facteur de correction moins fort (par exemple 1.1 au lieu de la valeur par défaut 1.5), ce que je vous encourage à faire pour les images Calcium (conserver le 1.5 pour le h-alpha, baisser pour le calcium) :

Le résultat dépendra cependant beaucoup de l’exposition initiale de votre vidéo. Voici un autre exemple en raie calcium K:

Il est utile de noter que si vous n’êtes pas satisfait du nouvel algorithme, il est tout à fait possible de repasser à CLAHE :

Enfin, il vous est tout à fait possible d’être plus ou moins "aggressif" sur l’amélioration de constraste à effectuer. Ansi, dans les paramètres de traitement, vous pouvez changer le facteur gamma qui permet d’assombrir l’image. Pour l’exemple, si on pousse les curseurs un peu loin (par exemple à 4 dans l’image suivante), vous constaterez que l’image reste exploitable, et surtout que les défauts de CLAHE qui a tendance à aplatir les images est complètement disparu :

Tout d’abord, JSol’Ex offre un langage de script qui permet d’aller bien plus loin dans les traitements, de générer automatiquement des animations, etc. Bien sûr, les améliorations de JSol’Ex 2.2 sont disponibles dans les scripts par l’intermédiaire de 2 nouvelles fonctions : adjust_gamma qui permet de réaliser une simple correction de gamma sur l’image, et auto_constrast qui correspond à la correction décrite dans ce billet de blog.

Enfin, nous n’avons pas encore parlé des fonctionnalités désactivées par défaut, mais qui étaient déja disponibles dans JSol’Ex : la déconvolution et l’amélioration de la netteté. Ces deux options sont activables dans les paramètres de traitement :

Je ne recommande pas nécessairement de cocher la case "aiguiser les détails" si vous avez des images trop bruitées. Cette dernière ligne compare donc la même image, traitée avec INTI v6, JSol’Ex 2.2 (dernière version donc), mais sans déconvolution, avec déconvolution et finalement avec déconvolution et amélioration des détails :

En ce qui me concerne, je trouve la version déconvoluée particulièrement plaisante à l’oeil, et j’active donc systématiquement la déconvolution :

En conclusion, dans ce billet je vous ai présenté le nouvel algorithme de correction de contraste, activé par défaut dans JSol’Ex 2.2. Je pense que les résultats sont assez probants, et que JSol’Ex n’a plus à rougir de INTI en ce qui concerne les images avec amélioration de contraste. Cependant, je rappelle encore une fois que le logiciel officiel est INTI, que c’est le seul validé avec le sérieux de Christian Buil et Valérie Desnoux. Si vous voulez déposer des images sur BASS2000, vous devez utiliser INTI. Par ailleurs, je vous conseille toujours de comparer les résultats, ne considérez pas que JSol’Ex fait un meilleur travail, c’est probablement faux.

Par exemple, il reste des améliorations à faire sur les images calcium. Mais il est cependant tout à fait possible de modifier les paramètres par défaut, voire de changer d’algorithme.

N’oubliez pas non plus que JSo’Ex offre d’autres fonctionnalités comme la colorisation automatique des images, le stacking, la création de mosaïques solaires ou encore un langage de script particulièrement puissant, qui vous permet par exemple de générer des animations automatiquement. Je vais donc conclure ce billet avec un exemple de script qui utilise cette nouvelle amélioration de contraste pour produire une animation qui nous fait plonger dans l’atmosphère solaire en jouant sur le décalage de pixels :