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

Image processing does not kill people… and it's a shame

25 min.
Among the technical fields, quite a few have the potential to harm the public : the first that come to mind are medicine and civil engineering. Both have in common their scientific basis : studies, data, models and history form a corpus of knowledge and tools used by the practitioners to help making choices. However scientific their basis is, the practice remains an art or a craft. Indeed, while the state of the art provides models, data and methods, it is the practitioner’s responsibility to identify which model applies to the current circumstances, which tools are the best suited to the current situation, and which are the priorities that will make the best solution stand out of the reasonable ones.
Lire la suite →

The designer and the drilling machine

5 min.
As a designer, your job is to match someone’s needs/problems with a solution. The tricky part is, this someone is not necessarily the client you are talking with and who pays you, it could be a third party that you only know of through your paying client. As an engineer, the particular kind of design you do aims toward technical solutions, so you might produce plans, blueprints, calculations and prototypes to carry on with that goal.
Lire la suite →

Bilinear interpolation on images stored as Python Numpy ndarray

8 min.
If you are working in image processing and using Python as a prototyping script language to test algorithms, you might have noticed that all the libs providing fast image interpolation methods (to either sub-sample or over-sample) work in 8 bits unsigned integers (uint8). This is quite annoying if you are working with floating point images. PIL supports floating point interpolation , but only for one layer, thus forget about RGB, and scipy.
Lire la suite →

Derivating HDR-IPT direct and inverse transformations

53 min.
Following my work on the filmic tonemapping, several users have reported issues with very saturated blue areas (stage spotlights, bright skies) and red areas. The grail of image processing is being able to affect colors and brightness independantly. The big conundrum of tonemapping is raising luminance without affecting perceptual colors, and, by color, we mean hue and saturation/chroma. The problem is, once you lifted the luminance, you need to correct the saturation too, because it will look oversaturated.
Lire la suite →

Filmic, darktable and the quest of the HDR tone mapping

28 min.
Darktable  is an open-source software for raw photographs management and processing developped since 2009 for Linux desktops. Since then, it has been ported on Mac OS and Windows 7, 8, 10. After having used it for 7 years, I begun to develop in it 3 months ago. This article shows my work and results to improve the HDR-scenes handling in darktable, in a fashion that allows better color preservation for portrait photography.
Lire la suite →

Pages :
 ◉ 
 ◉ 


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.


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.