I’m a software developer, and if you are following me, you may also know that I’m an amateur astrophotographer. For a long time, I’ve been fascinated by the quality of software we have in astronomy, to process images. If you are french speaking, you can watch a presentation I gave about this topic. Naturally, I have been curious about how all these things work, but it’s actually extremely rare to find open source software, and when you do, it’s rarely written in Java. For example, both Firecapture (software to capture video streams) and Astro Pixel Processor are written in Java, but both of them are closed source, commercial software.

Last month, for my birthday, I got a Sol’Ex, an instrument which combines spectrography and software to realize amazing solar pictures in different spectral lines. To process those images, the easiest solution is to use the amazing INTI software, written in Python, but for which sources are not published, as far as I know, neither on GitHub or GitLab.

To give you an example of what you can do, here’s the first photography I’ve done with Sol’Ex and processed with INTI (color was added in Gimp):

To get this result, one has to combine images which look like this:

Interesting, no? At the same time, I was a bit frustrated by INTI. While it clearly does the job and is extremely easy to use, there are a few things which I didn’t like:

When I started studying at University, back in 1998, I was planning to do astrophysics. However, I quickly forgot about this idea when I saw the amount of maths one has to master to do modern physics. Clearly, I was reaching my limits, and it was extremely complicated for me. Fortunately, I had been doing software development for years already, because I started very young, on my father’s computer. So I decided to switch to computer science, where I was reasonably successful.

However, not being able to do what I wanted to do has always been a frustration. It is still, today, to the point that a lot of what I’m reading is about this topic, but still, I lack the maths.

It was time for me to confront my old demons, and answer a few questions:

Astro4j is there to answer those questions. I don’t have the answers yet and time will tell if I’m successful.

One question you may have is why Java? If you are not familiar with this language, you may have this old misconception that Java is slow. It’s not. Especially, if you compare to Python, it’s definitely not.

This project is also for me a way to prove that you can implement "serious science" in Java. You can already find some science libraries in Java, but they tend to me impractical to use, because not following the industry standards (e.g published on Maven Central) or platform-dependent.

I also wanted to leverage this to learn something new. So this project:

As I said, my initial goal is to obtain a software which can basically do what INTI does. It is not a goal to make it faster, but if I can do it, I will.

After a few evenings (and a couple week-ends ;)), I already have something which performs basic processing, that is to say that it can process a SER video file and generate a reconstructed solar disk. It does not perform geometry correction, nor tilt correction, like INTI does. It doesn’t generate shifted images either (for example the doppler images), but it works.

Since the only source of information I had to do this was Christian Buil’s website and Valérie Desnoux INTI’s website, I basically had to implement my own algorithms from A to Z, and just "guess" how it works.

In order to do this, I had to:

Here’s an example:

Then I could finally start working on the Sol’Ex video processor. As I said, I don’t know how INTI works, so this is all trial and error, in the end…​

In the beginning, as I said, you have a SER video file which contains a lot of frames (for example, in my case, it’s a file from 500MB to 1GB) that we have to process in order to generate a solar disk. Each frame consists of a view of the light spectrum, centered on a particular spectral line.

For example, in the following image, we have the H-alpha spectral line:

Because of optics, you can see that the line is not horizontal: each frame is distorted. Therefore, in order to reconstruct an image, we have to deal with that distortion first. For this, we have to:

Note that before doing this, I had no idea how to do a 2d order regression, but I searched and found that it was possible to do so using the least squares method, so I did so. The result is that we can identify precisely the line with this technique:

In the beginning, I tought I would have to perform distortion correction in order to reconstruct the image, because I was (wrongly) assuming that, because each frame represents one line in the reconstructed image, I had to compute the average of the colums of each frame to determine the color of a single pixel in the output. I was wrong (we’ll come to that later), but I did implement a distortion correction algorithm:

When I computed the average, the resulting image was far from the quality and constrast of what I got with INTI. What a failure! So I thought that maybe I had to compute the average of the spectral line itself. I tried this, and indeed, the resulting image was much better, but still not the quality of INTI. The last thing I did, therefore, was to pick the middle of the spectral line itself, and then, magically, I got the same level of quality as with INTI (for the raw images, as I said I didn’t implement any geometry or tilt correction yet).

The reason I was assuming that I had to compute an average, is that it wasn’t clear to me that the absorption ray would actually contain enough data to reconstruct an image. As it was an absorption ray, I assumed that the value would be 0, and therefore that nothing would come out of using the ray itself. In fact, my physics were wrong, and you must use that.

A direct consequence is that there is actually no need to perform a distortion correction. Instead, you can just use the 2d order polynomial that we’ve computed, and "follow the line", that’s it!

Now, we can generate an image, but it will be very dark. The reason is obvious: by taking the middle of the spectral line, we’re basically using dark pixels, so the dynamics of the image are extremely low. So, in order to have something which "looks nice", you actually have to perform brightness correction.

The first algorithm I have used is simply a linear correction: we’re computing the max and min value of the image, then rescaling that so that the max value is the maximum representable (255).

Here’s the result:

However, I felt that this technique wouldn’t give the best results, in particular because linear images tend to give results which are not what the eye would see: our eye performs a bit like an "exponential" accumulator, the more photos you get, the "brighter" we’ll see it.

So I implemented another algorithm which I had seen in PixInsight, which is called inverse hyperbolic (Arcsinh) correction:

Last, you can see that the image has lots of vertical line artifacts. This is due to the presence of dust either on the optics or the sensors. INTI performs correction of those lines, and I wanted to do something similar.

Again, I don’t know what INTI is doing, so I figured out my own technique, which is using "multipass" correction. In a nutshell, for each row, I am computing the average value of the row. Then, for a particular row, I compute the average of the averages of the surrounding lines (for example, 16 rows before and after). If the average of this line is below the average of the averages(!), then I’m considering that the line is darker than it should be, computing a correction factor and applying it.

The result is a corrected image:

We’re still not a the level of quality that INTI produces, but getting close!

So what’s next? I already have added some issues for things I want to fix, and in particular, I’m looking at improving the banding reduction and performing geometry correction. For both, I think I will need to use fast fourier transforms, in order to identify the noise in one case (banding) and detect edges in the other (geometry correction).

Therefore, I started to implement FFT transforms, a domain I had absolutely no knowledge of. Luckily, I could ask ChatGPT to explain to me the concepts, which made it faster to implement! For now, I have only implemented the Cooley-Tukey algorithm. The issue is that this algorithm is quite slow, and requires that the input data has a length which is a power of 2. Given the size of the image we generate, it’s quite costly.

I took advantage of this to learn about the Vector API to leverage SIMD instructions of modern CPUs, and it indeed made things significantly faster (about twice as fast), but still not at the level of performance that I expect.

I am trying to understand the split radix but I’m clearly intimidated by the many equations here…​ In any case I printed some papers which I hope I’ll be able to understand.

In conclusion, in this article, I’ve introduced astro4j, an open source suite of libraries and applications written in Java for astronomy software. While the primary goal for me is to learn and improve my skills and knowledge of the maths behind astronomy software processing, it may be that it produces something useful. In any case, since it’s open source, if you want to contribute, feel free!

And you can do so in different domains, for example, I pretty much s* at UI, so if you are a JavaFX expert, I would appreciate your pull requests!

Finally, here is a video showing JSol’Ex in action:

The Micronaut Framework is a modern open-source framework for building JVM applications. It can be used to build all kinds of applications, from CLI applications to microservices or even good old monoliths. It supports deploying both to the JVM and native executables (using GraalVM), making it particularly suitable for all kind of environments. A key feature of the Micronaut framework is developer productivity: we do everything we can to make things faster for developers. In particular, Micronaut has a strong emphasis on easing how you test your applications, even in native mode. For this we have built a number of tools, including our Maven and Gradle plugins.

When I joined the Micronaut team almost a couple years back, I was given the responsibility of improving the team’s own developer productivity. It was an exciting assignment, not only because I knew the team’s love about Gradle, but because I also knew that there were many things we could do to reduce the feedback time, to provide more insights about failures, to detect flaky tests, etc. As part of this work we have put in place a partnership with Gradle Inc which kindly provides us with a Gradle Enterprise instance, but this is not what I want to talk about today.

Lately I was listening to an interview of Aurimas Liutikas of the AndroidX team, who was saying that he didn’t think that version catalogs were a good solution for library authors to share their recommendations of versions, and that BOMs are probably a better solution for this. I pinged him saying that I disagreed with this statement and offered to provide more details why, if he was interested. This is therefore a long answer, but one which will be easier to find than a thread on social media.

Let’s start with the basics: a version catalog is, like the name implies, a catalog of versions to pick from, nothing more. That doesn’t sound too much exciting, and what versions are we talking about? That’s version of libraries or plugins that you use in your build.

As an illustration, here is a version catalog, defined as a TOML file:

Then this library can be used in a dependencies declaration block in any of the project’s build script using a type-safe notation:

which is strictly equivalent to writing:

There are many advantages of using version catalogs to declare your library versions, but most notably it provides a single, standard location where those versions are declared. It is important to understand that a catalog is simply a list of dependencies you can pick from, a bit like going to the supermarket and choosing whatever you need for your particular meal: it’s not because a catalog declares libraries that you have to use them. However, a catalog provides you with recommendations of libraries to pick from.

An interesting aspect of version catalogs is that they can be published, for others to consume: they are an artifact. Micronaut users can already make use of catalogs, as I have explained in a previous blog post. This makes it possible for a user who doesn’t know which version of Micronaut Data to use, to simply declare:

People familiar with Maven BOMs can easily think that it is the same feature, but there are key differences which are described in the Gradle docs.

In the rest of this post we will now focus on how we generate those catalogs, and how they effectively help us in improving our own developer productivity.

All that I described in this article aren’t the only benefits that we have on standardizing on version catalogs. For example, we have tasks which allow us to check that our generated BOM files only reference dependencies which are actually published on Maven Central, or that there are no SNAPSHOT dependencies when we perform a release. In the end, while most of the Micronaut developers had no idea what a version catalog was when I joined the team, all of them pro-actively migrated projects to use them because, I think, they immediately saw the benefits and value. It also streamlined the dependency upgrade process which was still a bit cumbersome before, despite using dependabot.

We now have a very pragmatic way to both use catalogs for building our own projects, and generating BOMs and version catalogs which can be used by both our Maven and Gradle users. Of course, only the Gradle users will benefit from the version catalogs, but we did that in a way which doesn’t affect our Maven users (and if you use Maven, I strongly encourage you to evaluate building Micronaut projects with Gradle instead, since the UX is much better).

I cannot end this blog post without mentioning a "problem" that we have today, which is that if you use Micronaut Launch to generate a Micronaut project, then it will not use version catalogs. We have an issue for this and pull requests are very welcome!

I have tried several options before this one, which I’m going to explain below, but let’s focus with the final design (at least at the moment I write this blog post). The matrix of artifacts to be generated can be configured in the settings.gradle file:

The generates a number of synthetic Gradle projects, that is to say "projects" in the Gradle terminology, but without actually duplicating sources and directories on disk. With the example above, we generate the following projects:

To build the fat jar of the "tcnative on", "epoll on", "Jackson", "Micronaut 4.0" on Java 17 combination, you can invoke:

And building the native image of the "tcnative off", "epoll on", "Micronaut Serde", "Micronaut 3.8" on Java 17 combination can be done with:

Cherry on the cake, all variants can be built in parallel by executing either ./gradlew shadowJar (for the fat jars) or ./gradlew nativeCompile (for the native binaries), which would copy all the artifacts under the root projects build directory so that they are easy to find in a single place.

In a typical project, say the Micronaut application we want to benchmark, you would have a project build which consists of a single Micronaut application module. For example, running ./gradlew build would build that single project artifacts. In a multi-project build, you could have several modules, for example core and app, and running :core:build would only build the core library and :app:build would build both core and app (assuming app depends on core. In both cases, single or multi-project builds, for a typical Gradle project, there’s a real directory associated for each project core, app, etc, where we can find sources, resources, build scripts, etc.

For synthetic projects, we actually generate Gradle projects (aka modules) programmatically. We have a skeleton directory, called test-case-common, which actually defines our application sources, configuration files, etc. It also contains a build script which applies a single convention plugin, named io.micronaut.testcase. This plugin basically corresponds to our "baseline" build: it applies the Micronaut plugin, adds a number of dependencies, configures native image building, etc.

Then the "magic" is to use Gradle’s composition model for the variant aspects. For example, when we define the tcnative dimension with 2 variants on and off, we’re modeling the fact that there are 2 possible outcomes for this dimension. In practice, enabling tcnative is just a matter of adding a single dependency at runtime:

The dimension which handles the version of Java (both to compile and run the application) makes use of Gradle’s toolchain support:

This can be done in a convention plugin which is named against the dimension variant name: io.micronaut.testcase.tcnative.on. In other words, the project with path :test-case:tcnative-off:epoll-off:json-jackson:micronaut-3.8:java-11 will have a "synthetic" build script which only consists of applying the following plugins:

Each of these plugins can be found in our build logic. As you can see when browsing the build logic directory, there is actually one small optimization: it is not necessary to create a variant script if there’s nothign to do. For example, in practice, tcnative off doesn’t need any extra configuration, so there’s no need to write a io.micronaut.testcase.tcnative.off plugin which would be empty in any case.

In this blog post, we have seen how we can leverage Gradle’s flexibility to support what seemed to be a complicated use case: given a common codebase and some "small tweaks", generate a matrix of builds which are used to build different artifacts, in order to benchmark them.

The solution turned out to be quite simple to implement, and I hope pretty elegant, both in terms of user facing features (adding dimensions and configuring the build should be easy), maintenance (composition over inheritance makes it very simple to understand how things are combined) and implementation.

Many thanks to Jonas Konrad for the feature requests and for reviewing this blog post!

Tours, ça n’est pas si loin de chez moi, environ 200km. J’avais donc décidé de m’y rendre avec mon e-208, dont l’autonomie théorique, avec sa batterie de 50kW (disponible 46kW), est annoncée à 340km. J’ai fais l’acquisition de cette voiture il y a 2 ans, et j’en suis globalement très content : j’habite en zone rurale, nous n’avons pas de transports en commun, et cette voiture sert donc pour tous les trajets du quotidien. Je peux la recharger à la maison sans problème. Jusqu’ici, les trajets les plus longs que j’avais effectué étaient sans recharge : des allez-retours à Pornic, où j’ai de la famille, soit environ 160 km aller/retour, et ça se passait très bien, en particulier l’été.

Maintenant, entre l’autonomie théorique et la réalité, il y a un monde, en particulier en hiver. J’étais donc assez nerveux à l’idée de me retrouver "en rade" avant d’arriver sur Tours, et j’ai donc planifié mon déplacement avec l’application ChargeMap (j’ai une carte chez eux et l’application Peugeot est franchement pas top, impossible de planifier aussi bien).

Je voulais faire l’aller-retour dans la journée, ce qui impliquait de pouvoir recharger en arrivant sur Tours. Un des problèmes, c’est que les bornes de recharge "rapides" ne sont pas si nombreuses. Autre problème : il est impossible de savoir si une borne va être occupée lorsqu’on y arrivera. La 208 dispose d’une prise combo CCS qui accepte une charge à 100kW.

J’avais donc 2 choix:

J’ai choisi la première option, parce que j’avais un doute que la borne soit occupée en arrivant, et que je doive donc faire 10 min de route de plus pour me rendre à la borne rapide et donc perdre du temps. Par ailleurs, ça n’est pas super pratique que de devoir quitter la conférence et marcher 1km (potentiellement sous la pluie) dans la journée.

En bref, j’ai planifié pour être tranquille. Voici les conditions du trajet:

L’application ChargeMap dispose d’une fonctionnalité qui lui permet d’envoyer le trajet planifié sur Google Maps, que j’ai utilisé pour le guidage. Ça se passait très bien, jusqu’à ce que j’arrive après Saumur où je me rends compte que le GPS avait décidé de me faire prendre l’autoroute ! Problème, je n’avais clairement pas assez d’autonomie pour rouler à 130 km/h. Ne pouvant pas rouler à 90 km/h sur autoroute, trop dangereux, je suis donc monté à 110 km/h et autant dire que vu les conditions météo (froid), mon autonomie restante fondait comme neige au soleil. Je suis donc sorti un peu plus loin pour finir le trajet en passant par les bords de Loire, comme c’était initialement prévu.

Au final, je suis arrivé sur ma borne de recharge Allego, au Casino de La Riche, à 8h08 : 180km en 2h36. De mémoire (l’appli Peugeot récupère les trajets, mais pas la consommation, incroyable ce retard du logiciel par rapport à la concurrence !), ma consommation moyenne était de l’ordre de 16kWh/100km. Je me suis branché et j’ai chargé pendant 49 minutes pour atteindre 90% de batterie, soit 29kW, facture: 31,38€, pas franchement économique (1.082€ du kWh !). Je me suis arrêté à 90% parce que la recharge "ralentit" à mesure qu’on s’approche de la charge maximale : il m’aurait fallu rester encore une bonne demi-heure (voire plus) pour atteindre les 100%, et je souhaitais me rendre à la conférence.

Je suis donc arrivé sur Polytech’Tours à 9h12, soit 3h40, à comparer aux 2h25 si j’étais parti avec ma 407 diesel, qui ferait l’aller-retour sans aucun pb sans faire le plein (autonomie environ 950km…​).

Pour le retour, je savais donc que je serai très juste et qu’il faudrait probablement que je fasse un arrêt supplémentaire pour recharger (à cause des 10% de batterie en moins au départ). Je ne suis pas passé par l’autoroute au retour, et donc suivi les bords de Loire. Les conditions météo étaient similaires, mais avec plus de pluie. J’ai surveillé mon autonomie, et si au départ, j’avais une marge de 100km entre l’autonomie annoncée par la voiture (c’est à dire qu’en suivant ses indications, je serais à la maison avec 100km d’autonomie restante), au fur et à mesure du trajet, cette estimation a sensiblement baissé. Arrivé à Cholet (environ 40km de chez moi), il ne restait plus que 60 km de marge, alors que j’avais baissé la température dans l’habitacle à 16 degrés. Encore une fois, je roulais en mode éco, souple, pas de bouchons, rien. En clair, l’estimation d’autonomie, c’est du grand n’importe quoi et complètement irréaliste (à noter, qu’en été, c’est bien plus proche de la réalité).

Bref, j’avais aussi faim et n’étant pas très joueur, je me suis arrêté sur une borne rapide en chemin, à côté d’une pizzeria, au SIEML de l’Ecuyère. Comme je savais que quel que soit le temps de charge, j’aurais de quoi rentrer large, j’ai juste pris le temps de manger. Je récupère ma voiture, pas mal, 22,7kW de récupérés en 35 minutes de charge, pour 9.62€ : 3 fois moins cher que la recharge à Tours (mais à comparer aux 0.14€/kWh quand je charge à la maison…​).

L’expérience fut concluante : je sais que je peux faire ce genre de trajets, moyennant quelques concessions (heure d’arrivée tardive à cause de la recharge à l’arrivée, trajet sans autoroute, confort "limité", etc), mais c’est à peu près la distance maximale que je puisse faire sans que ça ne devienne trop pénible. En revanche, je reste très mitigé sur l’autonomie "réelle" : ici, j’étais plus proche des 200 km en faisant tout pour économiser. Même en conditions idéales, jamais, ô grand jamais, je n’atteindrais les 340 km (le mieux, c’est environ 300km). Le logiciel est aussi bien trop basique comparé à la concurrence (oui, Tesla) : l’application mobile manque de fonctionnalités de base (blocage de charge, récupération des consommations, …​) et le GPS pour planifier un trajet est franchement nul. L’estimation de l’autonomie restante est irréaliste et pire, on ne sait pas vraiment où on en est de charge: l’indicateur à la "jauge d’essence" n’est pas adapté à une batterie (dites moi le % restant, c’est plus parlant !). Enfin, un des gros soucis reste la recharge et les tarifs hallucinants qui sont pratiqués : il est pour ainsi dire impossible de savoir combien va vous coûter un trajet, puisqu’en fonction des conditions, vous allez devoir vous arrêter, ou non, et que les tarifs varient en fonction de la puissance de recharge, du fournisseur, etc.

Lorsqu’on part en thermique, on sait que le carburant coûte environ 1.9€/L, à 25% près : en électrique, oubliez. Vous pouvez faire du simple au quadruple. Est-ce à dire que je ne recommande pas l’électrique ? Pas du tout ! Déjà, je préfère 100 fois le confort de la conduite en électrique au thermique. La voiture est aussi super agréable à conduire et la puissance disponible immédiatement est un indéniable atout de l’électrique.

Mon alternative, sur ce trajet, aurait été de prendre ma voiture thermique, mais ça aurait été la solution de facilité. Et compte-tenu de l’urgence climatique, j’ai fais le choix de perdre un peu de confort, pour le bien de ma conscience :)