Inside
the Lab.

A significant part of the early work centred on Photoshop plugins and panels for astrophotography. The aim was practical: simplify a workflow that many users found fragmented, generic and poorly matched to astronomical imaging.

Photoshop is an extraordinary instrument, but it was not designed around astronomical data. Support requests kept returning to the same points: workflows that were too complex, general-purpose operations adapted to unusually delicate data, and tools that did not begin with astronomical noise, stars, gradients, faint structure or restoration in mind.

Eventually, adding another layer on top of a platform built for something else stopped feeling like the answer.

We needed something more specific. Models built around astronomical data from the beginning.

That was the point at which the idea of SyQon became concrete.

Axiom V1 worked. It was also far too heavy for much of the consumer hardware it was meant to serve. Technically, it was interesting. Practically, it was much less convincing.

That first limitation taught us a principle that still shapes every model and every product decision: a system must not merely function in a controlled environment. It has to function in the real world—on real computers, with real datasets and within the time available to someone who wants to finish an image.

In that sense, SyQon's history did not begin with an early success. It began when we understood precisely why the first attempt was not good enough.

New neural architectures—especially hybrid and proprietary systems—are built through experimentation. Experimentation is expensive, both technically and financially.

A training run can look promising for hours or days and then reveal that it is going nowhere. An architectural change may improve one class of data while making another worse. An idea that appears elegant on paper can collapse as soon as it meets real astronomical images.

Today, SyQon uses professional GPU infrastructure, with individual instances that can cost several dollars for every hour of training. At the beginning, resources were far more limited. A failed experiment could mean stopping, waiting for the next available budget and hoping that a new customer would place enough trust in us to continue.

Our earliest customers were never simply the first orders. They became part of the company's history. We have not forgotten that.

One of the most important steps in SyQon's growth did not come from a paid product. It came when we released Zenith—a branch born from the work on Axiom V2—to the Siril community for free.

The response was larger than we expected. People tried SyQon, shared results, reported problems, proposed ideas and discussed the work directly with us. More importantly, they began participating in the evolution of the products.

That experience clarified something fundamental: SyQon should not be only a company that develops software for astrophotographers. It should be community first.

We owe a great deal to the Siril community. We continue to recognise that through free models, practical support and, whenever possible, financial contributions to open-source projects that matter to the imaging ecosystem.

At first, Michael worked almost entirely alone, bringing in outside professionals when a particular discipline was needed. Then the project began to grow.

Occasional collaborators became permanent colleagues. Developers, engineers, UI/UX specialists and people focused on infrastructure, research, customer support and operations joined the work.

SyQon has Italian roots, but the team now works across several parts of the world. That structure lets us maintain near-continuous progress without building a culture around night shifts: as one part of the team ends its day, another can begin.

We are a distributed group of people who—perhaps through questionable judgement—remain genuinely interested in the difficult problems. That is an important part of our identity.

“Community first” is not copy written for a landing page. It means the product is not developed in isolation.

If a feature fails, we want to know. If a workflow is unclear, we want to understand why. If a particular configuration behaves badly, we want to reproduce it. If a decision is unconvincing, we want to hear the reasoning behind that reaction.

This does not mean that every request becomes a feature, or that every comment decides the roadmap. It means that the people using SyQon should know there is no wall on the other side.

There is a team.

In less than a year, SyQon moved from an Axiom model that was too slow to a complete family of neural models, a growing software ecosystem and more than 4,000 customers.

We do not present that number as a trophy. To us, it is primarily a responsibility. The growth of the models allowed us to reinvest progressively in people, research, infrastructure and hardware, until SyQon Studio became possible.

Studio marks the point at which SyQon stops being only a collection of models and becomes a complete ecosystem: an environment where processing, neural systems, workflows, files, integrations and automation can live together instead of being passed between unrelated tools.

Our future direction is simple to explain and difficult to realise. We believe astrophotography can become much more accessible without becoming more superficial.

Advanced technology should not necessarily require years of experience before it can be used correctly. Complexity can remain inside the system. The experience around it can become clearer.

Neural imaging, computational photography, automation, software and—in the future—SyQon AI hardware all belong to the same direction. The objective is not to remove control from the astrophotographer. It is to make tools available that, until recently, were accessible to very few people.

For us, the future is highly complex technology made simple to use. And we are still at the beginning.