Today I am going to share a discovery that might not be newsworthy for many people, but for me it seemed somewhat scanadalous at first. Could it really be true that an oversight of this kind slips through the cracks and makes it to the front page of publicly released NASA pictures? Apparently yes. This talk is about missing gamma correction in some space images which therefore give an unrealistic appearance. This issue seems to exist on top of the color-filter issue (where the imaging instruments mostly do not have spectral sensitivities that correspond to human vision) and results in a distortion of brightness relationships between objects. Extra caution is therefore advised when using these images as a reference for artistic purposes.
I remember how in 2015 an image of a lunar transit taken by the Earth Polychromatic Imaging Camera (EPIC) made rounds in several twitter threads. These transits happen regularly, the latest one being from february this year. There’s just one problem with these images as originally published on the NASA website: they’re too dark. As if somebody took the files with the linear photon counts from the scientific instruments, and threw them together to make the images while forgetting to account for display gamma.
This post is a quick annoucement that I changed the main text and math fonts and hopefully for the better.
Background: This blog runs on WordPress, using an almost vanilla TwentyEleven theme and using the QuickLaTeX plugin for math typesetting. But while WordPress uses a default sans-serif font (it explicitly prefers Helvetica but also accepts any lookalike) the default font in is usually Computer Modern, a completely difference typeface. So with standard settings, there was always going to be a font mismatch between text and math.
In order to mitigate this, I previously found Computer Modern Bright as an alternative font (see the old announcement post) that is a better match with Helvetica. CM Bright is one of the few sans-serif fonts in that has full math support. But CM Bright also has issues, for example it is hard distinguish lowercase l from uppercase I, and some of the generated SVGs do not render correctly, especially if they are images of single letters.
Now I switched the main body text to Times, or whatever the browser’s default serif font is. This is then combined with the newtx-package on the -side, so now text and math use the same font (at least theoretically). See how this turns out for yourself:
a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9
The top row is text-mode (your browser’s version of Times or a substitute), the bottom row is math-mode (a rendered SVG image by ). In both cases, the requested font size is explicitly 16 pixels. It is expected that the match is not perfect, especially that the metrics will be slightly different, but overall it should be an improvement. I am aware that common wisdom usually says that serif fonts are bad for online viewing, but hasn’t this advice become obsolete with high-DPI displays? And boy does the Times font look sharp and serious! Every blog post now automatically looks like a paper.
It is usually said that the colors of noise are inspired by the spectral distributions of corresponding colors of light. For example, the ‘white’ in white noise is an allusion to white light which is thought to have a (mostly) flat spectrum. But is this so? How does white light actually look like, as an electromagnetic wave?
So I made following figure which shows some power-law distributions in the visible range of wavelengths colored by their theoretical appearance:
Fig 1: Spectral distributions with exponents from 0 to −4.
Just a quick post to report on my findings of measuring the energy impact of three different ways to have Spotify playing in the background: the Spotify app and the web player using two different browsers (Safari and Firefox).
Inspection of the package contents of the desktop app reveals it to be just a container version of the web player, bringing with it its own instance of a Chromium Embedded framework (for a whopping 168 MB, no less). So what we are really seeing is the performance of the web player in three different browser engines.
So here are the numbers, taken from the ‘energy’ tab in Activity Monitor, on a Mac Book Pro 15″ (2017), and in all cases the window was invisible off-screen*. I also included iTunes playing a local file for comparison:
Web player in Safari 14.0
Web player in Firefox 86
Spotify App 1.1.53 (Chromium embedded)
(*the respective app was first expanded full screen, and then the focus was switched back to the desktop so that the app window was totally not shown, not even a minimized window or icon)
And the winner for running Spotify with the least energy impact is actually the Safari browser. Congratulations to the Apple engineering team! The desktop app running Chromium Embedded comes second (but with a curiously high idle activity), while Firefox only comes last.
In the hope that this information was useful, make of it as you will :)
EDIT: I just learned that the web player does not support loudness normalization so it is not even an apples-to-apples comparison!
(Edit 2021: In the latest Safari 14.2 the Shadertoy does not work and my crash or hang the display. This is unfortunately a regression.)
This is a quick post thrown together to report on my experience with the new Safari 14 regarding support for WebGL 2. The news of improved WebGL support was floated last month in the Shadertoy Community Group:Fast forward to today and the Safari 14 update has now come to my laptop (which still runs macOS Mojave). So the first thing I did check out all my shaders on Shadertoy and then some to see if the promises were true. My verdict (TL/DR):
In order to keep this site spam free I approve every comment by hand. This means that comments will not immediately appear after posting.
Unfortunately, comments tend to appear in bursts. There can be long stretches of no activity (where I get nothing but spam), during which I will get lazy and will tend to check less and less often, only to be surprised when there are multiple legit comments waiting (usually after a link has been posted to social media).
So if you think your post got stuck just try again.
This is a brain-dump inspired by a thread on twitter about correct™ dither in sRGB, meaning, to choose the dither pattern in such a way as to preserve the physical brightness of the original pixels. This is in principle a solved problem, but the devil is in the details that are easily overlooked, especially when dithering to only a few quantization levels.
So, this topic came up on twitter:
I had previously spent some time to wrap my head around this exact problem, so I shot from the hip with some pseudo code that I used in Space Glider on Shadertoy. Code postings on twitter are never a good idea, so here is a cleaned up version wrapped up in a proper function:
The slides of my 2013 talk at FMX in Stuttgart were available for download for a long time now in both Keynote and Powerpoint formats. However, people keep asking for a PDF version. As I wrote in the comments once, I always had bad luck with the PDF export from Keynote, so I left it at that.
Yesterday I made a major discovery: The option “export to PDF” is not the only possibility, in fact, it is quite an inferior one. The thing that I overlooked is that one can also just pretend to “print”, and then, in the subsequent printer dialog, chose “save to PDF” instead. Not only does this give additional options but also produces nicer formatting and a smaller file!
I wonder however the UI designers at Apple really intended this to be the primary means of PDF export?
Anyway, I updated the slides to PDF format and also made some minor corrections. I exchanged the font Humanist 521 with Gill Sans. Apparently the former is an official clone of the latter, and since Gill Sans is preinstalled on a Mac anyway, I may as well just use the original. The metrics also seem to look nicer in the PDF. I also copy-edited some of the notes to be more educational than just a transcript of my talk.
I found the reason for why sometimes all Latex in my posts got clobbered. The culprit was an outdated plugin, which—as a side effect—deleted backslashes from posts. So I deinstalled the sinner and also repaired all math that I found was broken. If you still find broken math, drop me a line.
This post is the first in a series to follow-up on my 2012 GPU Pro 3 article about atmospheric scattering . What I showed there was a full single-scattering solution for a planetary atmosphere running in a pixel shader, dynamic and in real time, without pre-computation or simplifying assumptions. The key to this achievement was a novel and efficient way to evaluate the Chapman function , hence the title. In the time since then I have improved on the algorithm and extended it to include aspects of multiple scattering. The latter causes horizontal diffusion (twilight situations) and vertical diffusion (deep atmospheres), and neither can be ignored for a general atmosphere renderer in a space game, for example.
I have written a Shadertoy that reflects the current state of affairs. It’s a mini flight simulator that also features clouds, and other rendering goodies. A WebGL 2 capable browser is needed to run it. Under Windows, the ANGLE/Direct 3D translator may take a long time to compile it (up to a minute is nothing unusual, but it runs fast afterwards). When successfully compiled it should look like this: Weiterlesen →