Caveat: Even NASA pictures may not be linear (or the wrong kind of linear)

Today I am going to share a dis­cov­ery that might not be news­wor­thy for many peo­ple, but for me it seemed some­what scanadalous at first. Could it real­ly be true that an over­sight of this kind slips through the cracks and makes it to the front page of pub­licly released NASA pic­tures? Appar­ent­ly yes. This talk is about miss­ing gam­ma cor­rec­tion in some space images which there­fore give an unre­al­is­tic appear­ance. This issue seems to exist on top of the col­or-fil­ter issue (where the imag­ing instru­ments most­ly do not have spec­tral sen­si­tiv­i­ties that cor­re­spond to human vision) and results in a dis­tor­tion of bright­ness rela­tion­ships between objects. Extra cau­tion is there­fore advised when using these images as a ref­er­ence for artis­tic purposes.

The Lunar Transit picture

Lunar tran­sit as cap­tured by the EPIC cam­era on board of the Deep Space Cli­mate Obser­va­to­ry. Left: image as pub­lished; right: corrected.

I remem­ber how in 2015 an image of a lunar tran­sit tak­en by the Earth Poly­chro­mat­ic Imag­ing Cam­era (EPIC) made rounds in sev­er­al twit­ter threads. These tran­sits hap­pen reg­u­lar­ly, the lat­est one being from feb­ru­ary this year. There’s just one prob­lem with these images as orig­i­nal­ly pub­lished on the NASA web­site: they’re too dark. As if some­body took the files with the lin­ear pho­ton counts from the sci­en­tif­ic instru­ments, and threw them togeth­er to make the images while for­get­ting to account for dis­play gam­ma.

Weit­er­lesen

Style change – \usepackage{newtxmath}

This post is a quick annouce­ment that I changed the main text and math fonts and hope­ful­ly for the better.

Back­ground: This blog runs on Word­Press, using an almost vanil­la Twen­tyEleven theme and using the Quick­La­TeX plu­g­in for math type­set­ting. But while Word­Press uses a default sans-serif font (it explic­it­ly prefers Hel­veti­ca but also accepts any looka­like) the default font in \LaTeX is usu­al­ly Com­put­er Mod­ern, a com­plete­ly dif­fer­ence type­face. So with stan­dard set­tings, there was always going to be a font mis­match between text and math.

In order to mit­i­gate this, I pre­vi­ous­ly found Com­put­er Mod­ern Bright as an alter­na­tive \LaTeX font (see the old announce­ment post) that is a bet­ter match with Hel­veti­ca. CM Bright is one of the few sans-serif fonts in \LaTeX that has full math sup­port. But CM Bright also has issues, for exam­ple it is hard dis­tin­guish low­er­case l from upper­case I, and some of the gen­er­at­ed SVGs do not ren­der cor­rect­ly, espe­cial­ly if they are images of sin­gle letters.

Now I switched the main body text to Times, or what­ev­er the browser’s default serif font is. This is then com­bined with the newtx-pack­age on the \LaTeX-side, so now text and math use the same font (at least the­o­ret­i­cal­ly). 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

    \[\text{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 ver­sion of Times or a sub­sti­tute), the bot­tom row is math-mode (a ren­dered SVG image by \LaTeX). In both cas­es, the request­ed font size is explic­it­ly 16 pix­els. It is expect­ed that the match is not per­fect, espe­cial­ly that the met­rics will be slight­ly dif­fer­ent, but over­all it should be an improve­ment. I am aware that com­mon wis­dom usu­al­ly says that serif fonts are bad for online view­ing, but has­n’t this advice become obso­lete with high-DPI dis­plays? And boy does the Times font look sharp and seri­ous! Every blog post now auto­mat­i­cal­ly looks like a paper.

White Light equals Brown Noise

Here is a recent show­er thought:

It is usu­al­ly said that the col­ors of noise are inspired by the spec­tral dis­tri­b­u­tions of cor­re­spond­ing col­ors of light. For exam­ple, the ‘white’ in white noise is an allu­sion to white light which is thought to have a (most­ly) flat spec­trum. But is this so? How does white light actu­al­ly look like, as an elec­tro­mag­net­ic wave?

So I made fol­low­ing fig­ure which shows some pow­er-law dis­tri­b­u­tions in the vis­i­ble range of wave­lengths col­ored by their the­o­ret­i­cal appearance:

Fig 1: Spec­tral dis­tri­b­u­tions with expo­nents from 0 to −4.

The col­or of the flat line is also known as Stan­dard Illu­mi­nant E‍‍ – or equal-ener­gy white light. Com­pared to the D65 white back­ground it has a rather pink­ish appear­ance with a cor­re­lat­ed col­or tem­per­a­ture of about 5500 K.

Weit­er­lesen

Spotify Performance

Just a quick post to report on my find­ings of mea­sur­ing the ener­gy impact of three dif­fer­ent ways to have Spo­ti­fy play­ing in the back­ground: the Spo­ti­fy app and the web play­er using two dif­fer­ent browsers (Safari and Fire­fox).

Inspec­tion of the pack­age con­tents of the desk­top app reveals it to be just a con­tain­er ver­sion of the web play­er, bring­ing with it its own instance of a Chromi­um Embed­ded frame­work (for a whop­ping 168 MB, no less). So what we are real­ly see­ing is the per­for­mance of the web play­er in three dif­fer­ent brows­er engines.

So here are the num­bers, tak­en from the ‘ener­gy’ tab in Activ­i­ty Mon­i­tor, on a Mac Book Pro 15″ (2017), and in all cas­es the win­dow was invis­i­ble off-screen*. I also includ­ed iTunes play­ing a local file for comparison:

idle play­ing
Web play­er in Safari 14.0 < 0.1 2.1
Web play­er in Fire­fox 86 < 0.1 13.8
Spo­ti­fy App 1.1.53 (Chromi­um embedded) 2.3 3.4
iTunes 12.9 < 0.1 1.7

(*the respec­tive app was first expand­ed full screen, and then the focus was switched back to the desk­top so that the app win­dow was total­ly not shown, not even a min­i­mized win­dow or icon)

And the win­ner for run­ning Spo­ti­fy with the least ener­gy impact is actu­al­ly the Safari brows­er. Con­grat­u­la­tions to the Apple engi­neer­ing team! The desk­top app run­ning Chromi­um Embed­ded comes sec­ond (but with a curi­ous­ly high idle activ­i­ty), while Fire­fox only comes last.

In the hope that this infor­ma­tion was use­ful, make of it as you will :)

EDIT: I just learned that the web play­er does not sup­port loud­ness nor­mal­iza­tion so it is not even an apples-to-apples comparison!

Safari 14, Shadertoy and WebGL 2

(Edit 2021: In the lat­est Safari 14.2 the Shader­toy does not work and my crash or hang the dis­play. This is unfor­tu­nate­ly a regression.)

This is a quick post thrown togeth­er to report on my expe­ri­ence with the new Safari 14 regard­ing sup­port for WebGL 2. The news of improved WebGL sup­port was float­ed last month in the Shader­toy Com­mu­ni­ty Group:Fast for­ward to today and the Safari 14 update has now come to my lap­top (which still runs macOS Mojave). So the first thing I did check out all my shaders on Shader­toy and then some to see if the promis­es were true. My ver­dict (TL/DR):

Weit­er­lesen

Sorting through comment spam is burdensome

In order to keep this site spam free I approve every com­ment by hand. This means that com­ments will not imme­di­ate­ly appear after posting.

Unfor­tu­nate­ly, com­ments tend to appear in bursts. There can be long stretch­es of no activ­i­ty (where I get noth­ing but spam), dur­ing which I will get lazy and will tend to check less and less often, only to be sur­prised when there are mul­ti­ple legit com­ments wait­ing (usu­al­ly after a link has been post­ed to social media).

So if you think your post got stuck just try again.

Correct sRGB Dithering

This is a brain-dump inspired by a thread on twit­ter about cor­rect™ dither in sRGB, mean­ing, to choose the dither pat­tern in such a way as to pre­serve the phys­i­cal bright­ness of the orig­i­nal pix­els. This is in prin­ci­ple a solved prob­lem, but the dev­il is in the details that are eas­i­ly over­looked, espe­cial­ly when dither­ing to only a few quan­ti­za­tion levels.

So, this top­ic came up on twitter:

I had pre­vi­ous­ly spent some time to wrap my head around this exact prob­lem, so I shot from the hip with some pseu­do code that I used in Space Glid­er on Shader­toy. Code post­ings on twit­ter are nev­er a good idea, so here is a cleaned up ver­sion wrapped up in a prop­er function:

Weit­er­lesen

Update of my 2013 FMX Slides on Physically Based Shading in PDF format

The slides of my 2013 talk at FMX in Stuttgart were avail­able for down­load for a long time now in both Keynote and Pow­er­point for­mats. How­ev­er, peo­ple keep ask­ing for a PDF ver­sion. As I wrote in the com­ments once, I always had bad luck with the PDF export from Keynote, so I left it at that.

Yes­ter­day I made a major dis­cov­ery: The option “export to PDF” is not the only pos­si­bil­i­ty, in fact, it is quite an infe­ri­or one. The thing that I over­looked is that one can also just pre­tend to “print”, and then, in the sub­se­quent print­er dia­log, chose “save to PDF” instead. Not only does this give addi­tion­al options but also pro­duces nicer for­mat­ting and a small­er file!

I won­der how­ev­er the UI design­ers at Apple real­ly intend­ed this to be the pri­ma­ry means of PDF export? 

Any­way, I updat­ed the slides to PDF for­mat and also made some minor cor­rec­tions. I exchanged the font Human­ist 521 with Gill Sans. Appar­ent­ly the for­mer is an offi­cial clone of the lat­ter, and since Gill Sans is pre­in­stalled on a Mac any­way, I may as well just use the orig­i­nal. The met­rics also seem to look nicer in the PDF. I also copy-edit­ed some of the notes to be more edu­ca­tion­al than just a tran­script of my talk.

Here is again, the direct down­load link.

Down­load “FMX 2013 Slides PDF with Notes” fmx-11-revised.pdf – 2032-mal herun­terge­laden – 15 MB

Outbound link manager plugin is incompatible with QuickLatex

I found the rea­son for why some­times all Latex in my posts got clob­bered. The cul­prit was an out­dat­ed plu­g­in, which—as a side effect—deleted back­slash­es from posts. So I dein­stalled the sin­ner and also repaired all math that I found was bro­ken. If you still find bro­ken math, drop me a line.

Followup to Atmospheric Scattering – Part 1: Overview

This post is the first in a series to fol­low-​up on my 2012 GPU Pro 3 arti­cle about atmos­pher­ic scat­ter­ing [11]. What I showed there was a full sin­gle-​scat­ter­ing solu­tion for a plan­e­tary atmos­phere run­ning in a pix­el shad­er, dynam­ic and in real time, with­out pre-​com­pu­ta­tion or sim­pli­fy­ing assump­tions. The key to this achieve­ment was a nov­el and effi­cient way to eval­u­ate the Chap­man func­tion [2], hence the title. In the time since then I have improved on the algo­rithm and extend­ed it to include aspects of mul­ti­ple scat­ter­ing. The lat­ter caus­es hor­i­zon­tal dif­fu­sion (twi­light sit­u­a­tions) and ver­ti­cal dif­fu­sion (deep atmos­pheres), and nei­ther can be ignored for a gen­er­al atmos­phere ren­der­er in a space game, for example.

I have writ­ten a Shader­toy that reflects the cur­rent state of affairs. It’s a mini flight sim­u­la­tor that also fea­tures clouds, and oth­er ren­der­ing good­ies. A WebGL 2 capa­ble brows­er is need­ed to run it. Under Win­dows, the ANGLE/Direct 3D trans­la­tor may take a long time to com­pile it (up to a minute is noth­ing unusu­al, but it runs fast after­wards). When suc­cess­ful­ly com­piled it should look like this:
Weit­er­lesen