Navigation

Engineering

#Presentation

I do research and development in applied mathematics for digital art matters, mostly photography, typically involving some physics and computer programming. With the maths models I built, I design end-user software and applications. For the applications I built, I design websites, write documentations and shoot educational videos. For the (scattered) documentations I wrote, I designed an (unified) AI-driven search engine.

I’m one of the very few open-source developers who write down the maths before opening their IDE to code anything silly. I have lost too much time because someone (sometimes me) tried hack something quickly and validated it on a non-significant sample where “it worked”. From cursory reading of such code, I can nowadays typically predict in which cases the hacks will fail, but without being able to propose a fix, because you can’t fix something that doesn’t state its goal in maths terms (especially since it gets buried into contextual technicalities as soon as computers are involved). Theory and abstraction win over inductivism  and should be used from the inception of the project if you want to make good use of your time.

Engineering is the art of designing solutions supported by scientific knowledge and optimized by numerical simulation.

Designing is deciding, deciding is choosing priorities, and no amount of science will ever tell what you should rather choose: it is a discussion between you and your values. What science tells engineers is how to achieve a goal, not which goal to pick. What engineers sometimes forget is they are only fooling themselves when they hide behind numbers to make their choices look more objective. What non-engineers don’t know is design is not just bending technology to deliver something ASAP: technology is only one mean to an end, not the only one, not always the best one. What both — engineers or not — often overlook is it’s often better, and usually simpler, to fix workflows rather than to fix tools, which involves understanding the needs (past the requests), educating, communicating and changing habits but little to no design.1 Nevertheless, since those are typically not the forte of the guys enjoying science, technology and technics, everyone stays in their silo of expertise, looks for solutions under the lamp post , and when you have a hammer, everything looks like a nail.

Design stems from a definite goal, clearly understood, expressed in technical terms, and objectively measurable. From there, means are unrolled and tuned until we reach optimality of the solution under the given set of constraints. Hacks are thoughtless happy accidents guaranteed to backfire because they start and end with “doing”. You can’t improve on hacks, at best you can add alternative hacks. Since open-source is made of saturday-afternoon pet projects, that’s all you will get for your money though.

This is where I publish those maths, to serve as addendum to my code, and other research or reflections on design and software.


Trained in applied physics, then metrology and finally mechanical engineering, I’m only interested in scientific computation and numerical simulation of physical processes. I had to step on software engineer’s feet because it seems they can’t be entrusted neither with end-user applications nor with vector algebra2. In the process, I have grown an acquired taste for end-user interfaces design.

I only use computers to solve real-world problems that require math processing, don’t mistake me for a technophile. My super-power is I hate programming, which makes me favour lean and simple solutions requiring the least amount of code, libs, deps, tech stacks and therefore the least amount of maintenance.

In a typical day, I write C, OpenCL and Python. I had to become proficient in PHP, Javascript, LaTeX and CSS for my websites and documentations. Since I moved all my websites to Hugo and had to build a custom template from scratch, I started writing a bit of Go as well.

I am very concerned by the inflationary spiral that is software and IT : there is no concept of “enough” software, we always need another layer and it’s often to work around the problems created by the previous layer. It also turns out that the next layer will often be more CPU-hungry than the previous.

That only leads to more energy consumption, device obsolescence, and yet fails to make workers more efficient (or people happier): they have to battle against more ever-changing tools and fix more post-upgrade messes. “One-size-fits-all” ACME  frameworks are to blame here, along with the don’t reinvent the wheel dogma : people will install sprawling toolkits and bloated plugins, only to use a few features that could be replaced by 5-15 lines of custom code, just to avoid writing code themselves (or paying someone to do it). I find that people overestimate the burden that is maintaining their own simple code and underestimate the burden of debugging their whole third-party software stack through possibly-incompatible upgrades.


  1. Of course, in an economy based on selling products and in a world where people hate change, it’s more lucrative to fix tools and sell upgrades. Loop over that for 10 years and that’s how you get madness-triggering software, only good for feature fatigue ↩︎

  2. Brains shutdown when equations show up – maybe one day I will understand why –, but it’s a shame because to avoid a couple of equations, coding monkeys get dozens of PDF pages explaining what they should implement mindlessly, which give them no chance to understand when it would be good to move away from the specifications they are reading. ↩︎

 ◉ 

Latest posts

You need to reinvent the wheel all the time

Opinion 7 min.
There is this mantra that I have been hearing too much in my life : “don’t reinvent the wheel”. People mean that as a metaphor trying to discourage you from redoing something that is already done, and by that they actually want you to use whatever software application or library instead of coding your own, as if it was automatically a time and resource saver. It’s not. First of all, despite its apparent common sense, this statement is incredibly ignorant : the wheel has been reinvented many times, typically for the sake of performance.
Lire la suite →

Design by committee will not save FLOSS

Opinion 6 min.
The opensource ecosystem is keen on its mantras. One of them is that being an opensource dev/maintainer is a thankless unpaid job. And while that may sound like a selfless act of benevolence, there is another way of reading it : a selfish way of avoiding professional responsibility, while still exerting some amount of power and decision. Which is the egg and which is the chicken then ? It may not matter, but the quasi-hagiographic founding myths of opensource need to stop.
Lire la suite →

Interpolating (hue) angles

Study 9 min.
In image processing, retouchers may want to apply a saturation boost on specific hues only. Typically, uniform saturation corrections follow a basic linear transfer function $sat_{out} = gain \cdot sat_{in}$, where $gain$ is a real positive constant. To target specific hues, we simply rewrite $sat_{out}(hue) = gain(hue) \cdot sat_{in}$ where $gain$ is then a function. The most common way to declare $gain$ is to provide users with 8 discrete saturation nodes for 8 evenly-spaced hues, and interpolate smoothly between nodes.
Lire la suite →

Open source and professional photography : lies and wishes

Opinion 8 min.
There is one thing you will find on the home page of pretty much any open source (call it libre or free if you will, those lines are blurred) image editing software : the promise that it is, somehow, suitable for professionals. Marketing has abused that word for decades, it is only natural that it should affect non-commercial and non-profit projects as well, just to try to buy some cheap credibility.
Lire la suite →

Color saturation control for the 21th century

75 min.
The saturation control of pretty much all image processing software is an unfortunate misnomer, to say the least. It actually controls either the chroma in Ych-like spaces (computed from CIE Yxy 1931, Yuv or YCbCr spaces), or some remote idea of saturation as used by HSL spaces, which are essentially a polar rewriting of RGB coordinates (usually expressed in sRGB space). The “saturation” as defined by the HSL space has been proven times and times again to hold no perceptual meaning and finds its origin into the first GUI of limited computers doing integer arithmetic.
Lire la suite →

Pages :
 ◉ 
 ◉ 

Author

Profile picture

Patrons Income Goal

I use computers to solve real-world problems that require physical simulation and math processing with some user interface on top. My super-power is I hate programming, meaning my programs are simple, lean and to-the-point. I code mostly open-source but my days of free-software advocate ended when I started contributing to said software and realized the average open-source developer is a clueless amateur. I'm done with FLOSS "communities", birthing 5-legged sheeps nobody else wants to use, failing to see the difference between democracy and design by commitee. There is no collective intelligence where there is no structure to organize it between individually-skilled persons, and that's a strong assumption on people's invidual intelligence in a development model where having freetime is the foremost skill.

Credits

This website uses neither cookies, nor personal data tracking system, nor advertising service. Multimedia players embedded on pages can use their own cookies and trackers.