fleabitdev

Experienced software developer, looking for freelance work or full-time employment.

    Location: UK
    Remote: Yes (or hybrid within the UK)
    Willing to relocate: No
    Resume/CV: By request
    Email: (my username) at protonmail dot com

Particularly good at cleaning up messes! Suitable freelance contracts might include legacy module rewrites, performance improvements, or the daunting new feature which nobody on your team wants to tackle.

I can be flexible on time zones. No interest in relocating long-term, but I'd be happy to visit your team in person for a few days to break the ice.

My specialist skills:

- The Rust language, which has been my daily driver for more than a decade.

- Multimedia (video, audio, image processing, 2D rendering...)

- Performance optimisation (SIMD, GPGPU, parallel programming...)

Fields in which I'm highly experienced, but below specialist level:

- Full-stack web development, with a frontend bias (TypeScript, React, WebGL, WebAssembly, AWS...)

- Native development, especially low-level Win32.

- Communication and technical writing, both learned in a previous career.

I also have a modest level of experience in computer vision, greenfield R&D, game engine development, programming language development, and data compression. I can offer a 50% discount for any contract which seems highly educational; my current areas of interest include DSP, embedded programming, robotics, functional languages, Swift, and React Native.

Thanks for reading, and I look forward to hearing from you :-)

Experienced software developer, mostly looking for freelance work, but also happy to discuss full-time employment.

    Location: UK
    Remote: Yes
    Willing to relocate: No
    Resume/CV: By request
    Email: (my username) at protonmail dot com

Particularly good at cleaning up messes! Suitable contracts might include legacy module rewrites, performance improvements, or the daunting new feature which nobody on your team wants to tackle.

I can be flexible on time zones. No interest in relocating long-term, but I'd be happy to visit your team in person for a few days to break the ice.

My specialist skills:

- The Rust language, which has been my daily driver for more than a decade.

- Multimedia (video, audio, 2D rendering...)

- Performance optimisation (SIMD, GPGPU, parallel programming...)

Fields in which I'm highly experienced, but below specialist level:

- Web development, with a frontend bias (TypeScript, React, WebGL, WebAssembly...)

- Native development, especially low-level Win32.

- Communication and technical writing, both learned in a previous career.

I also have a modest level of experience in computer vision, greenfield R&D, game engine development, programming language development, and data compression. I can offer a 50% discount for any contract which seems highly educational; my current areas of interest include DSP, embedded programming, robotics, functional languages, Swift, and React Native.

Thanks for reading, and I look forward to hearing from you :-)

Experienced software developer, currently available for freelance work.

    Location: UK
    Remote: Yes
    Willing to relocate: No
    Resume/CV: By request
    Email: (my username) at protonmail dot com

Particularly good at cleaning up messes! Suitable contracts might include legacy module rewrites, performance improvements, or the daunting new feature which nobody on your team wants to tackle.

I can be flexible on time zones. No interest in relocating long-term, but I'd be happy to visit your team in person for a few days to break the ice.

My specialist skills:

- The Rust language, which has been my daily driver for more than a decade.

- Multimedia (video, audio, 2D rendering...)

- Performance optimisation (SIMD, GPGPU, parallel programming...)

Fields in which I'm highly experienced, but below specialist level:

- Web development, with a frontend bias (TypeScript, React, WebGL, WebAssembly...)

- Native development, especially low-level Win32.

- Communication and technical writing, both learned in a previous career.

I also have a modest level of experience in computer vision, greenfield R&D, game engine development, programming language development, and data compression. I can offer a 50% discount for any contract which seems highly educational; my current areas of interest include DSP, embedded programming, Svelte, functional languages, Swift, and React Native.

Thanks for reading, and I look forward to hearing from you :-)

Wikimedia Commons has this feature. Editors can manually bless certain combinations of traits as "subcategories".

For example, https://commons.wikimedia.org/wiki/Category:Paintings_of_cas... contains the subcategories "Paintings of castles by country" (nested hierarchy), "Frescos of castles" (a medium), "Paintings of Château de Chillon" (a subject), and "Young Knight in a Landscape by Carpaccio" (multiple views onto a specific item). Each item may appear in multiple subcategories. As far as I can tell, the UI won't let you search for frescos of Italian castles (unless somebody's made a subcategory for that), or view all paintings of castles regardless of their subcategory.

I'm not very fond of this approach. I'd prefer for each item to have an unstructured set of tags ("fresco", "depiction of a castle", "depiction of Italy"), with automatic derivation of parent tags ("fresco" implies "painting") and the option to search by multiple tags. It should be possible to automatically discover tags which best refine a search, so that the UI can still suggest them to the user, as it does today.

> opt-in affects the data so much it becomes useless (much smaller sample and probably self-selecting a certain type of user)

Selection bias is a real problem, but small sample sizes may be less troublesome than you expect.

For example, when estimating a value by taking the mean of several samples, the random error of your estimate will be proportional to `1 / sqrt(number_of_samples)`. Scaling from one sample to 100 will improve the precision of your estimate by one decimal place, but to find a second decimal place, you'd need to scale from 100 samples to 10,000.

Some of telemetry's bad reputation comes from the common practice of gathering and storing exhaustive data for every user, usually with only half-hearted anonymisation. Sampling a small fraction of users (perhaps 10% for small projects, 0.01% for huge projects) should capture many of the benefits of comprehensive telemetry, with less privacy risk.

Good catch - looks like it's a PNG image, with an alpha channel for the rounded corners, and a subtle gradient in the background. The gradient is rendered with dithering, to prevent colour banding. The dither pattern is random, which introduces lots of noise. Since noise can't be losslessly compressed, the PNG is an enormous 6.2 bits per pixel.

While working on a web-based graphics editor, I've noticed that users upload a lot of PNG assets with this problem. I've never tracked down the cause... is there a popular raster image editor which recently switched to dithered rendering of gradients?

As I understand it, very small neural networks have already been incorporated into both VVC and AV2 for intra prediction. You're correct that this strategy is limited by decoding performance, especially when predicting large blocks.

I'm pessimistic about the prediction-and-residuals strategy for lossy compression. It tends to amplify noise; it creates data dependencies, which interfere with parallel decoding; it requires non-local optimisation in the encoder; really good prediction involves expensive analysis of a large number of decoded pixels; and it all feels theoretically unsound (because predictors usually provide just one value, rather than a probability distribution).

I'm more optimistic about lossy compression techniques based on explicitly-coded summary statistics, with very little prediction. That approach worked well for lossy JPEG XL.

JPEG XL achieves about half the bitrate of an equal-quality JPEG, even at lower quality levels. That's a real achievement, but the complexity cost is high; I'd estimate that JPEG XL decoders are at least ten times more complex than JPEG decoders. Modern lossy image codecs are "JPEG, with three decades of patch notes" :-)

I think we're badly in need of an entirely new image compression technique; the block-based DCT has serious flaws, such as its high coding cost for edges and its tendency to create block artefacts. The modern hardware landscape is quite different from 1992, so it's plausible that the original researchers might have missed something important, all those years ago.

I only recently learned that JPEG and MPEG-1 were designed for near-lossless compression, so the massive bitrate reductions which came further down the road had nothing to do with the original design.

"Inelegant" is the right word; it's hard to shake off the feeling that we might have missed something important. I suspect the next big breakthrough might be waiting for researchers to focus on lower-quality compression specifically, rather than requiring every new codec to improve the state of the art in near-lossless compression.

Both formats are DCT-based (except for lossless JPEG XL). JPEG 2000's use of the DWT was unusual; in general, still-image lossy compression research has spent the last 35 years iteratively improving on JPEG's design. This is partly for compatibility reasons, but it's also because the original design was very good.

Since JPEG, improvements have included better lossless compression (entropy coding) of the DCT coefficients; deblocking filters, which blur the image across block boundaries; predicting the contents of DCT blocks from their neighbours, especially prediction of sharp edges; variable DCT block sizes, rather than a fixed 8x8 grid; the ability to compress some DCT blocks more aggressively than others within the same image; encoding colour channels together, rather than splitting them into three completely separate images; and the option to synthesise fake noise in the decoder, since real noise can't be compressed.

You might be interested in this paper: https://arxiv.org/pdf/2506.05987. It's a very approachable summary of JPEG XL, which is roughly the state of the art in still-image compression.

The discrete wavelet transform (DWT) compresses an image by repeatedly downscaling it, and storing the information which was lost during downscaling. Here's an image which has been downscaled twice, with its difference images (residuals): https://commons.wikimedia.org/wiki/File:Jpeg2000_2-level_wav.... To decompress that image, you essentially just 2x-upscale it, and then use the residuals to restore its fine details.

Wavelet compression is better than the block-based DCT for preserving sharp edges and gradients, but worse for preserving fine texture (noise). The DCT can emulate noise by storing just a couple of high-frequency coefficients for a 64-pixel block, but the DWT would need to store dozens of coefficients to achieve noise synthesis of similar quality.

The end result is that JPEG and JPEG 2000 achieve roughly the same lossy compression ratio before image artefacts show up. JPEG blurs edges, JPEG 2000 blurs texture. At very low bitrates, JPEG becomes blocky, and JPEG 2000 looks like a low-resolution image which has been upscaled (because it's hardly storing any residuals at all!)

FFmpeg has a `jpeg2000` codec; if you're interested in image compression, running a manual comparison between JPEG and JPEG 2000 is a worthwhile way to spend an hour or two.

I'd describe that as a trend, rather than a consensus.

It wasn't an entirely bad idea, because comments carry a high maintenance cost. They usually need to be rewritten when nearby code is edited, and they sometimes need to be rewritten when remote code is edited - a form of coupling which can't be checked by the compiler. It's easy to squander this high cost by writing comments which are more noise than signal.

However, there's plenty of useful information which can only be communicated using prose. "Avoid unnecessary comments" is a very good suggestion, but I think a lot of people over-corrected, distorting the message into "never write comments" or "comments are a code smell".

You've rediscovered a state-of-the-art technique, currently used by JPEG XL, AV1, and the HEVC range extensions. It's called "chroma from luma" or "cross-component prediction".

This technique has a weakness: the most interesting and high-entropy data shared between the luma and chroma planes is their edge geometry. To suppress block artefacts near edges, you need to code an approximation of the edge contours. This is the purpose of your quadtree structure.

In a codec which compresses both luma and chroma, you can re-use the luma quadtree as a chroma quadtree, but the quadtree itself is not the main cost here. For each block touched by a particular edge, you're redundantly coding that edge's chroma slope value, `(right_chroma - left_chroma) / (right_luma - left_luma)`. Small blocks can tolerate a lower-precision slope, but it's a general rule that coding many imprecise values is more expensive than coding a few precise values, so this strategy costs a lot of bits.

JPEG XL compensates for this problem by representing the local chroma-from-luma slope as a low-resolution 2D image (one "pixel" per 8x8 block), and then recursively compressing that data as a lossless JPEG XL image. This is similar to your idea of using PNG-like compression (delta prediction, followed by DEFLATE).

Of course, since you're capable of rediscovering the state of the art, you're also capable of improving on it :-)

One idea would be to write a function which, given a block of luma pixels, can detect when the block contains two discrete luma shades (e.g. "30% of these pixels have a luminance value close to 0.8, 65% have a luminance value close to 0.5, and the remaining 5% seem to be anti-aliased edge pixels"). If you run an identical shade-detection algorithm in both the encoder and decoder, you can then code chroma information separately for each side of the edge. Because this would reduce edge artefacts, it might enable you to make your quadtree leaf nodes much larger, reducing your overall data rate.

When working as a senior engineer, I've never been given enough business context to confidently say, for example, "this stakeholder isn't important enough to justify such a tight deadline". Doesn't that leave the business side of things as a mysterious black box? You can't do much more than report "meeting that deadline would create ruinous amounts of technical debt", and then pray that your leader has kept some alternatives open.

Just a misunderstanding, then - thanks for taking the time to clear it up, I appreciate it.

Strange that your company calls its tech leads "senior engineers", when every other company is going through title inflation! Hiring for those roles must be a pain.

I agree, but I think that input is limited to unopinionated information about the technical impact or user-facing impact of each task.

I don't think it can be said that senior engineers persuade their leaders to take one position or the other, because you can't really argue against a political or financial decision using technical or altruistic arguments, especially when you have no access to the political or financial context in which these decisions are made. In those conversations, "we need to do this for the good of the business" is an unbeatable move.

> Influencing without authority

> Getting work prioritized

> Developing 1YP+ plans for their areas

I was a little surprised by your list. Aren't these normally the responsibilities of a team lead or a manager? If I were hired as a senior engineer, I'd expect to be involved in group decisions about cross-cutting technical concerns (architecture, choosing languages and frameworks, the code review process), but changing my team's priorities would fall well outside the job description.

If somebody has the power to tell me what to prioritise, it feels topsy-turvy for them to ask me to tell them what they should tell me to prioritise. At that point, why have a leader at all?

There was a constraint - since 2009, the Joint Photographic Experts Group had published JPEG XR, JPEG XT and JPEG XS, and they were probably reluctant to break that naming scheme.

They're running out of good options, but I hope they stick with it long enough to release "JPEG XP" :-)

The rods are only active in low-light conditions; they're fully active under the moon and stars, or partially active under a dim street light. Under normal lighting conditions, every rod is fully saturated, so they make no contribution to vision. (Some recent papers have pushed back against this orthodox model of rods and cones, but it's good enough for practical use.)

This assumption that rods are "the luminance cells" is an easy mistake to make. It's particularly annoying that the rods have a sensitivity peak between the blue and green cones [1], so it feels like they should contribute to colour perception, but they just don't.

[1]: https://en.wikipedia.org/wiki/Rod_cell#/media/File:Cone-abso...

Protanopia and protanomaly shift luminance perception away from the longest wavelengths of visible light, which causes highly-saturated red colours to appear dark or black. Deuteranopia and deuteranomaly don't have this effect. [1]

Blue cones make little or no contribution to luminance. Red cones are sensitive across the full spectrum of visual light, but green cones have no sensitivity to the longest wavelengths [2]. Since protans don't have the "hardware" to sense long wavelengths, it's inevitable that they'd have unusual luminance perception.

I'm not sure why deutans have such a normal luminous efficiency curve (and I can't find anything in a quick literature search), but it must involve the blue cones, because there's no way to produce that curve from the red-cone response alone.

[1]: https://en.wikipedia.org/wiki/Luminous_efficiency_function#C...

[2]: https://commons.wikimedia.org/wiki/File:Cone-fundamentals-wi...

In strategy games, I always find transport vehicles and garrisons a little awkward. When units can be in play without being physically present on the playing field, it adds a footnote to almost every rule of the game.

I like the way it's streamlined in Age of Wonders: some tiles are "roads", so land units can move along them quickly, and some units are "seafaring", so they can move over both land and water tiles. You're led to assume that carts and boats are involved, but there's no need for the player to micromanage them.

I'd be very interested in hearing alternative estimates, but here's my working:

The lowest cost I could find to rent a server SSD was US$5 per TB-month, and it's often much higher. If we assume that markets are efficient (or inefficient in a way that disadvantages gaming PCs), we could stop thinking there and just use US$2.50 as a conservative lower bound.

I checked the cost of buying a machine with a 2 TB rather than 1 TB SSD; it varied a lot by manufacturer, but it seemed to line up with $2.50 to $5 per TB-month on a two-to-five-year upgrade cycle.

One reason I halved the number is because some users (say, a teenager who only plays one game) might have lots of unused space in their SSD, so wasting that space doesn't directly cost them anything. However, unused storage costs money, and the "default" or "safe" size of the SSD in a gaming PC is mostly determined by the size of games - so install size bloat may explain why that "free" space was purchased in the first place.

> whether "marginal cost of wasted hard drive storage" is even a thing for consumers

As long as storage has a price, use of storage will have a price :-)

Isn't it a little reductive to look at basic infrastructure costs? I used Hetzner as a surrogate for the raw cost of bandwidth, plus overheads. If you need to serve data outside Europe, the budget tier of BunnyCDN is four times more expensive than Hetzner.

But you might be right - in a market where the price of the same good varies by two orders of magnitude, I could believe that even the nice vendors are charging a 400% markup.

In this case, the bug was 131 GB of wasted disk space after installation. Because the waste came from duplicate files, it should have had little impact on download size (unless there's a separate bug in the installer...)

This is why the cost of the bug was so easy for the studio to ignore. An extra 131 GB of bandwidth per download would have cost Steam several million dollars over the last two years, so they might have asked the game studio to look into it.

Back of the envelope, in the two years since the game was released, this single bug has wasted at least US$10,000,000 of hardware resources. That's a conservative estimate (20% of people who own the game keep it installed, the marginal cost of wasted SSD storage in a gaming PC is US$2.50 per TB per month, the install base grew linearly over time), so the true number is probably several times higher.

In other words, the game studio externalised an eight-figure hardware cost onto their users, to avoid a five-to-six-figure engineering cost on their side.

Data duplication can't just be banned by Steam, because it's a legitimate optimisation in some cases. The only safeguard against this sort of waste is a company culture which values software quality. I'm glad the developers fixed this bug, but it should never have been released to users in the first place.

Experienced software developer, currently available for freelance work. I'd be happy to sign either a conventional months-long software development contract, or a short consulting contract.

    Location: UK
    Remote: Yes
    Willing to relocate: No
    Resume/CV: By request
    Email: (my username) at protonmail dot com

My preferred coding style is high-rigour and highly-documented, which tends to be a great fit for contract work. I have a track record of delivering quality results under minimal supervision.

My specialist skills:

- The Rust language, which has been my daily driver for more than a decade.

- Multimedia (2D rendering, vector graphics, video, audio, libav, Web Codecs...)

- Performance optimisation (parallel programming, SIMD, GPU acceleration, soft-realtime programming...)

Fields in which I'm highly experienced, but below specialist level:

- Web development, with a frontend bias (TypeScript, React, JS build systems, the Web platform, WebGL, WebGPU, Node, WebAssembly...)

- Native development (native build systems, FFIs, low-level Win32, basic fluency in C/C++...)

- Leadership, communication and technical writing, all learned in a previous career.

I should also mention a modest level of experience in computer vision, greenfield R&D, game engine development, programming language development, and data compression. I'm comfortable with ubiquitous tools like Bash, Make, Git, GitHub, Docker and Figma. (Sorry for the keyword spam; you know how it is.)

I'm currently offering a 50% discount for any contract which seems highly educational. My areas of interest include acoustics, DSP, embedded programming, Svelte, Solid, functional languages, Swift, and backend development in general.

I can be flexible on time zones. No interest in relocating long-term, but I'd be happy to visit your team in person for a few days to break the ice.

Thanks for reading, and I look forward to hearing from you :-)

If you set out to build a practical UI from first principles using 1995 technology, I think you'd end up with something a lot like Windows 95. It's like a checklist of all the things we should be doing.

Luminance contrast is used to create a hierarchy of importance. Most backgrounds are medium grey, so that all text and icons are low-importance by default. Text fields, dropdowns, check boxes and radio buttons are black-on-white: a subtle call to action. Window, button and scrollbar edges always include pure white or pure black. Active toggle buttons have a light grey background, sacrificing the "3D shading" metaphor in the name of contrast.

Most colour is limited to two accents: pale yellow and navy blue. Small splashes of those colours are mixed together in icons to make them recognisable at a glance. Deactivated icons lose all colour. The grey, yellow and blue palette is highly accessible for colour-blind people, and the yellow and blue accents also occupy unique points in the luminance space (the yellow sits between white and grey, the blue sits between grey and black).

Despite all of this restraint, the designers weren't afraid of high contrast and high saturation; white text on a navy blue background shows up very sparingly, always as a loud "YOU ARE HERE" beacon. The designers understood that navigation is more important than anything else.

The graphics are strictly utilitarian, with no unnecessary texture or visual noise. The entire UI is typeset using just two weights of 9px MS Sans Serif. The only skeuomorphic elements are some program and folder names, a tiny resizing grip at the corner of each window, and a simple simulation of depth when push buttons are clicked. 3D edges are used to make the scene layout easier to parse, not to make it look physical or familiar.

Related components are almost always visually grouped together, using borders, filled rectangles and negative space. (I suspect the designers would have used fewer borders and more fills if the palette of background colours had been a little larger.) Dark and light backgrounds are freely mixed in the same UI, which requires both white and black text to be present. The depth of recursion (boxes in boxes in boxes...) is fairly shallow. Homogeneous collections of components are always enclosed in a strong border and background, which enables sibling components to be displayed with no borders at all between them.

All of these tasteful design choices were fragile, because you can only preserve them if you understand them. Windows XP made the background colours lighter, which reduced the available dynamic range of luminance cues; it tinted many backgrounds and components yellow or blue, which made chrominance more noisy; it introduced gradient fills and gradient strokes, which were less effective at grouping components; it added soft shading to icons, which made their shapes less distinct; and so on. Almost every change broke something, and so after just one major revision of the UI, most of the magic was already gone.

That could be made to work by stacking a transparent OLED panel in front of a transparent LCD panel. The LCD would absorb light, and the OLED would emit light.

I just tried to search for some examples, but I can't find any. Maybe the displays can't be made thin enough to eliminate parallax between the two images?

Interesting approach. It doesn't even introduce an extra rounding error, because converting from 32-bit XYB to RGB should be similar to converting from 8-bit YUV to RGB.

However, when decoding an 8-bit-quality image as 10-bit or 12-bit, won't this strategy just fill the two least significant bits with noise?

Emulators also struggle to faithfully reproduce artwork for the Game Boy Color and the original Game Boy Advance. Those consoles used non-backlit LCD displays with a low contrast ratio, a small colour gamut, and some ghosting between frames. Many emulators just scale the console's RGB colour values to the full range of the user's monitor, which produces far too much saturation and contrast.

It's a shame, because I really like the original, muted colour palette. Some artists produced great results within the limitations of the LCD screen. Similar to the CRT spritework in this article, it feels like a lost art.

However, there's an interesting complication: quite a lot of Game Boy Color and Game Boy Advance developers seem to have created their game art on sRGB monitors, and then shipped those graphics without properly considering how they would appear on the LCD. Those games appear muddy and colourless on a real console - they actually look much better when emulated "incorrectly", because the two errors exactly cancel out!