Pekka Väänänen
LightNews LightNews
banner
pekkavaa.bsky.social
Pekka Väänänen
@pekkavaa.bsky.social
1.1K followers 360 following 230 posts
Avid reader, computer graphics fan and atmospheric jungle beats enjoyer. Demoscene: cce/Peisik.

Blog at https://30fps.net/
Posts Replies Media Videos
pekkavaa.bsky.social
Alright actually there was a linear regression fit to the hue experiment data, presumably via the "reg post" and "reg pre" buttons in the screenshot earlier. Constraints such as constant lightness was verified visually by plotting other datasets. Makes sense Oklab could improve on it.
"The last control that was offered through the user interface was the ability to apply linear regression to either the pretransform matrix, or the posttransform matrix. The data used was the Ebner and Fairchild data set (306 points of constant hue on 15 different hue surfaces)."
November 27, 2025 at 2:00 PM
pekkavaa.bsky.social
Also, had to wait until page 107 before I found the first joke. And uh, the IPT color space based on the experimental data was interactively tweaked by hand in a GUI instead of a numerical fit?
"3.1.3.6 Observers 30 observers, 18 males and 12 females, between the ages of 27 and 59 participated in the experiment. The author was pleasantly surpnsed to learn that the lure of a free lunch would entice so many willing and qualified observers." A screenshot of a window titled "get it straight" of a complex Unix tool to tweak color space transform details and visualize its result in real time.
November 27, 2025 at 2:00 PM
pekkavaa.bsky.social
It's lovely when I see dedication to an experiment: keeping a CRT on for a month to avoid affecting its color reproduction. From Fritz Ebner's 1998 dissertation: repository.rit.edu/theses/2858/ The same hue matching experiment data was used by Björn Ottosson when creating the Oklab color space.
"The experiment was performed on a Sun Sparc Ultra 1 with a 20" Sony GDM-20E20 monitor. The resolution was 1152x900 with a refresh rate of 76 Hz and a 0.31mm-phosphor trio pitch. The CRT display was kept on during the extent of the experiment (which ran from May through July, 1997) to minimize drift from power cycling. The layout of the interface is shown in figure 31. The stimulus squares for both test and reference subtended an angle of 4.2 degrees."
November 27, 2025 at 2:00 PM
pekkavaa.bsky.social
I recently translated my book manuscript (it's about palettes) to Typst and been pretty happy so far. Today instead of writing I procrastinated by moving code snippets' line numbers over the left margin to salvage three extra characters of horizontal space😃
A snippet of my book manuscript that shows paragraphs of text around code snippet.s The line numbers of the code snippets are shifted left over the margin.
November 21, 2025 at 6:56 PM
pekkavaa.bsky.social
It's a good question. Fabien Sanglard's book suggests the palette conversion was done on a NeXT workstation before being transferred to a DOS machine for a Deluxe Paint clean up. But no mention of the palette origins.
October 31, 2025 at 9:14 AM
pekkavaa.bsky.social
What if Doom's "colormap" was computed in Oklab instead of RGB?

A short article about it on my site: 30fps.net/pages/doom-o...
A Doom screenshot using a slightly more accurate colormap for lighting. Of course differences to the original become apparent only in a side-by-side comparison. A crop comparison of the earlier image. On the left, the original has bright grey lines in a dark area. In the new version on the right, the lines are gone, making the image more even.
October 30, 2025 at 8:32 AM
pekkavaa.bsky.social
Relatable😑
From: doomwiki.org/wiki/Carmack...
The line in question: github.com/linguica/dmu...
Carmack's typo was a minor bug in dcolors.c, a program written by John Carmack in 1992 during early development of Doom. To generate the invulnerability colormap, Carmack converted each color in the palette to a gray scale value using a standard formula, where the gray scale value equals red*0.299 + green*0.587 + blue*0.114. In the utility, Carmack accidentally wrote 0.144 instead of 0.114, meaning that the invulnerability colormap converts all blues to be slightly too dark.[1] Since the invulnerability colormap inverts the gray scale palette, this means the gray scale colors converted from blue are calculated as brighter than they should be, and so become darker than they should be when the palette is inverted.
October 27, 2025 at 8:32 AM
pekkavaa.bsky.social
A new article: Why CIELAB doesn’t improve median cut

It's a common misconception that CIELAB will instantly improve palettes produced by the median cut algorithm. Unfortunately it's not that simple.

📜 30fps.net/pages/median...

It gets pretty technical but I added some context to the intro.
This graph shows how eager each color space is to minimize lightness error. The X-axis represents median cut’s splits as it works its way through clusters until all palette colors have been found. The Y-axis shows the sum of squared lightness errors of the whole image, measured as CIELAB’s L∗. I believe the low lightness weight is the main reason why median cut doesn’t work better in unscaled CIELAB than in sRGB.
October 24, 2025 at 12:50 PM
pekkavaa.bsky.social
New article on my site: Better sRGB to greyscale conversion

The commonly used greyscale formula is slightly off when computed in gamma space but can it be fixed?

📜 30fps.net/pages/better...
A four-pane comparison of different formulas for greyscale conversion. Top row: Linear sRGB (the correct way to do it), Gamma sRGB (the somewhat wrong "luma" formula). Bottom row: CIELAB L* (a high quality option), and the new alternative gamma-space version. Careful inspection shows the "Gamma sRGB" case is slightly dimmer at points than the others. A quote from “Principles of Digital Image Processing” by Wilhelm Burger and Mark J. Burge. It shows weights that are a better fit for gamma-space greyscale conversion.
October 13, 2025 at 5:56 PM
pekkavaa.bsky.social
My new visualization for color quantization algorithm execution, though still unfinished. Attached is the result for a simple 12-color median cut. Each box contains a subset of image colors with the X-axis as a chosen sort axis; Y is PCA for plotting. See how e.g. box 3 has unwanted greens in it.
A top-down hierarchical color quantization routine shown as a binary tree. The algorithm starts from the top box 1 that contains all image colors and continues splitting the box with the greatest error (in this case just max volume) into color subsets. Each box is split at the median, shown in red. Splitting stops when the requested number of colors has been reached. The mean colors of the leaf nodes at the bottom define the final 12-color palette. The final image and its palette (top right). I chose a purposefully primitive algorithm as a demonstration and the colors are a bit greyish and dim because of it.
October 7, 2025 at 7:32 AM
pekkavaa.bsky.social
A neat little paper from 2006 "A Median Cut Algorithm for Light Probe Sampling" where an environment map is compressed to a set of point lights using the median cut algorithm. Seems like a precursor to another 2007 paper where others cast the task as density estimation.
Figure 1: The Grace Cathedral light probe subdivided into 64 regions of equal light energy using the median cut algorithm. The small circles are the 64 light sources chosen as the energy centroids of each region; the lights are all approximately equal in energy. From Paul Debevec, "A Median Cut Algorithm for Light Probe Sampling" Comparison of median cut results using an HDRI and LDRI of memorial HDRI. a The memorial LDRI. b Median cut result, 1024 light sources generated starting from a LDRI. c Median cut result, 1024 light sources generated starting from a HDR From F. Banterle et al. "A framework for inverse tone mapping"
September 24, 2025 at 5:56 PM
pekkavaa.bsky.social
There's a classic color transfer technique from 2001: convert source and target image to a decorrelated color space (Oklab works fine), make target's mean and stddev match the source, convert back to RGB. Using a palette image as a target is no problem :)

Paper: home.cis.rit.edu/~cnspci/refe...
A diagram showing three images: the Source, a crop from Big Buck Bunny; the target image, the PICO-8 palette; and the result image. The result image's color distribution has been moved to match the target. Paper reference: "Color Transfer Between Images" Reinhard et al. 2001.
September 10, 2025 at 7:32 AM
pekkavaa.bsky.social
A short article on mapping pixel colors to the PICO-8 palette in the CAM16-UCS color space. Surprisingly, it didn't do much better than Oklab, which is derived from CAM16.

📜 30fps.net/pages/percep...
A four-pane comparison of pixel mapping results in CAM16-UCS, Oklab, and the CIELAB colorspace (HyAB distance function). Top right is the input image.
September 8, 2025 at 11:52 AM
pekkavaa.bsky.social
Got familiar with NumPy's structured arrays today. It's basically an Array Of Structs, where fields can of course be different types. Could be useful with binary files, but I used it to organize code. Adding a "record array" allows a nice `colors.r` access syntax.

numpy.org/doc/stable/u...
# First deduplicate the colors unique_colors, counts = deduplicate_colors(img.reshape(-1, 4)) # Create a structured array so that we can have float RGBA colors, per color weight and # the original RGBA8 color accessible and sortable with a single index. ColorRGBA = np.dtype([ ('r', 'f4'), ('g', 'f4'), ('b', 'f4'), ('a', 'f4'), ('weight', 'f4'), ('original', 'u4'), ]) colors = np.rec.array(np.zeros(unique_colors.shape[0], dtype=ColorRGBA)) colors.r = unique_colors[:, 0] / 255.0 colors.g = unique_colors[:, 1] / 255.0 colors.b = unique_colors[:, 2] / 255.0 colors.a = unique_colors[:, 3] / 255.0 colors.weight = counts / num_total colors.original = unique_colors.view(np.uint32).reshape(-1) # Scale the channels to weight luminance more when picking a split-plane axis. # This is why its convenient to store the original RGBA8 color: the final step # that averages colors for the palette doesn't need to know about this transform. colors.r *= 0.30 colors.g *= 0.59 colors.b *= 0.11 colors.a *= 0.50
September 3, 2025 at 6:52 PM
pekkavaa.bsky.social
I finally added alpha support to VariQuant. It took a lot of head-scratching to make it work with both RGB and L*a*b*😅 I premultiply the alpha and handle it like the other color channels. For RGBA color distance I'm using Kornel Lesiński's clever formula: stackoverflow.com/a/8796867
The screenshot shows the "VariQuant" tool interface with a preview panel displaying an image named "boom.png" The interface includes settings for the number of colors, cut order, split plane, split position ("Mean" is chosen), color space for palette design and pixel mapping, averaging, luminance-scale, and K-means iterations. File operation buttons for opening, exporting, canceling, and generating palettes are also visible.
August 27, 2025 at 5:56 PM
pekkavaa.bsky.social
Gamma correction seems to be one of those things where the more you read the less you know. Is it really true that the NTSC standard assumes a CRT gamma of 2.5 but encoding is done with 1/2.2 instead to add a little contrast boost? From Charles Poynton's 2002 article at poynton.ca/notes/colour...
A screenshot of a chapter in the linked article with the following text: "Does NTSC use a gamma of 2.2? Television is usually viewed in a dim environment. If an images's correct physical luminance is reproduced in a dim surround, a subjective effect called simultaneous contrast causes the reproduced image to appear lacking in contrast, as demonstrated above. The effect can be overcome by applying an end-to-end power function whose exponent is about 1.1 or 1.2. Rather than having each receiver provide this correction, the assumed 2.5-power at the CRT is under-corrected at the camera by using an exponent of about 1/2.2 instead of 1/2.5. The assumption of a dim viewing environment is built into video coding. " There's also and a visual test diagram with two columns. The left column has three squares in a vertical arrangement, each with varying shades of gray, transitioning from light to dark. The right column also has three squares in a vertical arrangement, each with the same shades of gray as the left column, but with a black background behind them. It looks like the one on the right with a black background has less contrast.
August 26, 2025 at 5:56 PM
pekkavaa.bsky.social
I've been improving my "VariQuant" color quantization tool. It now supports more color spaces, locally optimal cuts that guarantee the next color cluster split is the one that gives greatest decrease in error, luminance weight scaling, HyAB distance, A/B toggle, and palettes can be saved as PNGs :)
Screenshot of VariQuant with a still from the movie 2001: Space Odyssey. Palette file has been exported from the tool as a PNG. The palette is sorted horizontally by lightness and vertically by hue.
August 22, 2025 at 5:56 PM
pekkavaa.bsky.social
Here's a zoomed in portion of values near zero (note the uneven axis scaling) where cbrt(x) (green) shows a big difference to the almost-linear cbrt(x+b)-cbrt(b) (red). The blue vertical line is at x=1/255, for reference.

One of the authors discusses this on HN: news.ycombinator.com/item?id=2552...
August 20, 2025 at 5:56 PM
pekkavaa.bsky.social
I was studying the "XYB" color space today. It uses a cube root for gamma correction but instead of a linear "toe" like in sRGB, there's a bias in the inputs that gets subtracted afterwards. Should be simpler to compute. I was surprised how the curve doesn't reach 1.0 at the end!
August 20, 2025 at 5:56 PM
pekkavaa.bsky.social
I've been improving my experimental color quantization tool. It now supports separate palette design and pixel mapping color spaces with their own lightness weights. I added that palette visualization today and it's fun to play around the parameters and see it evolve.
A screenshot of "VariQuant", my color quantization (palette creation) tool. From left to right: the quantized result, a palette visualization sorted by hue on the vertical axis, and finally the quantization parameters that can be adjusted live.
August 13, 2025 at 11:52 AM
pekkavaa.bsky.social
I wrote earlier of a PCA approximation which worked surprisingly well. After some discussions, I now finally have a clear counter example where it fails. If the channels are uncorrelated, the result is an average that's clearly wrong.

Updated the article: 30fps.net/pages/approx...
A counter example where the PCA approximation fails. The cross shape consists of 200 points with 100 uniformly distributed both on the X and Y axes. However, the points on the X axis have twice the range, hence more variation. PCA (red) interpretes the situation correctly but the approximation (orange) fails.
August 7, 2025 at 11:52 AM
pekkavaa.bsky.social
Apparently in Python's dataclasses any member not set via the constructor gets ignored in equality checks. Both asserts pass in the code included code snippet. I put this example to a gist of it so I can reference it in the future: gist.github.com/pekkavaa/4a1...
from dataclasses import dataclass @dataclass class Data: value: int other = 1 # conceptually not part of a dataclass a = Data(0) b = Data(0) assert a == b, "values are equal" b.other = 100 assert a == b, "values are still equal!" print("a:", a) print("b:", a) # even in printouts "other" is ignored print("a == b:", a == b)
August 5, 2025 at 5:56 PM
pekkavaa.bsky.social
Interesting to see how in the original "The Irradiance Volume" paper from 1998 they stored irradiance per discrete direction instead of smooth spherical harmonics. Makes sense of course, it's basically a cubemap.
A diagram from "The Irradiance Volume" by Gene Greger, Peter Shirley, Philip M. Hubbard, and Donald P. Greenberg. 1998. A result render from "The Irradiance Volume" by Gene Greger, Peter Shirley, Philip M. Hubbard, and Donald P. Greenberg. 1998.
July 22, 2025 at 5:56 PM
pekkavaa.bsky.social
A new article on my site: Approximate first principal component

It describes simple trick to estimate the direction of most spread of a bunch of points without running a full PCA. Includes my Python re-implementation and plots of some quick tests.

30fps.net/pages/approx...
A plot comparing the original PCA and a simpler approximation. Accurate (red) and approximate (orange) first principal components are shown. The approximation seems close to the original based on this experiment. The shown directions are aggregated over five random trials.
July 17, 2025 at 5:56 PM
pekkavaa.bsky.social
I wanted to try using some experimental color quantization algorithms for a real project (on the N64) so I started working on a little GUI tool. Interactive parameter editing is already fun with that single color count slider😀 And tk's "Professional Motif Look" keeps expectations at the right level.
A screenshot of an image editing tool with three horizontal panels. The first two show versions of the same image, with the one on the right slightly degraded. The third column includes a single horizontal slider labelled "Colors", set to 16, and a "Generate palette" button. Looks like a professional UNIX tool!
July 17, 2025 at 11:52 AM