See What You Hear: Audio Calibration for Video Digitization

I’ve always been amused by the way a certain professional field frequently goes out of its way to shout “we don’t understand audio” to the world. (Association of Moving Image Archivists, Moving Image Archiving and Preservation, Moving Image Archive Studies, Museum of the Moving Image, etc. etc.)

“But there’s no good word to quickly cover the range of media we potentially work with,” you cry! To which I say, “audiovisual” is a perfectly good format-agnostic term that’s been in the public consciousness for decades and doesn’t confuse my second cousins when I try to explain what I do. “But silent film!” you counter, trying to use clever technicalities. To which I say, silent film was almost never really silent, home movies were meant to be narrated over, and stop being a semantic straw man when I’m trying to have a hot take over here!

The point is: when working in video preservation and digitization, our training and resources have a tendency to lean toward “visual” fidelity rather than the “audio” half of things (and it IS half). I’m as guilty of it as anyone. As I’ve described before, I’m a visual learner and it bleeds into my understanding and documentation of technical concepts. So I’m going to take a leap and try and address another personal Achilles’ heel: audio calibration, monitoring, and transfer for videotape digitization.

I hope this to be the first in an eventual two-part post (though both halves can stand alone as well). Today I’ll be talking about principles of audio monitoring: scales, scopes and characteristics to watch out for. Tune in later for a breakdown of format-by-format tips and tricks that vary depending on which video format you’re working with: track arrangements, encoding, common errors, and more. My focus, for now, is on audio in regards to videotape – audio-only formats like 1/4″ open reel, audio cassette, vinyl/lacquer disc and more bring their own concerns that I won’t get into right now, if only for the sake of scope crawl (I’ve been writing enough 3000+ word posts of late). But much if not all of the content in this post particularly should be applicable to audio-only preservation as well!

Big thanks to Andrew Weaver for letting me pick his brain and help spitball these posts!

The Spinal Tap Problem

Anyone who has ever attended one of my workshops knows that I love to take a classic bit of comedy and turn it into a buzz-killing object lesson. So:

Besides an exceptional sense of improvisational timing, what we have here is an excellent illustration of a fundamental disconnect in audio calibration and monitoring: the difference between how audio signal is measured (e.g. on a scale of 1 to 10) and how it is perceived (“loudness”).

There are two places where we can measure or monitor audio: on the signal level (as the audio passes through electrical equipment and wires, as voltage) or on the output level (as it travels through the air and hits our ears as a series of vibrations). We tend to be obsessed with the latter – judging audio based on whether it’s “too quiet” or “too loud”, which strictly speaking is as much a matter of presentation as preservation. Cranking the volume knob to 11 on a set of speakers may cause unpleasant aural side effects (crackling, popping, bleeding eardrums) but the audio signal as recorded on the videotape you’re watching stays the same.

To be clear, this isn’t actually any different than video signal: as I’ve alluded to in past posts, a poorly calibrated computer monitor can affect the brightness and color of how a video is displayed regardless of what the signal’s underlying math is trying to show you. So just as we use waveform monitors and vectorscopes to look at video signals, we need “objective” scales and monitors to tell us what is happening on the signal level of audio to make sure that we are accurately and completely transferring analog audio into the digital realm.

Just like different color spaces have come up with different scales and algorithms for communicating color, different scales and systems can be applied to audio depending on the source and/or characteristic in question. Contextualizing and knowing how to “read” exactly what these scales are telling us is something that tends to get lost by the wayside in video preservation, and what I’m aiming to demystify a bit here.

Measuring Audio Signal

So if we’re concerned with monitoring audio on the signal level – how do we do that?

All audiovisual signal/information is ultimately just electricity passed along on wires, whether that signal is interpreted as analog (a continuous wave) or digital (a string of binary on/off data points). So at some level measuring a signal quantitatively (rather than how it looks or sounds) always means getting down and interpreting the voltage: the fluctuations in electric charge passed along a cable or wire.

In straight scientific terms, voltage is usually measured in volts (V). But engineers tend to come up with other scales to interpret voltage that adjust unit values and are thus more meaningful to their own needs. Take analog video signal, for instance: rather than volts, we use the IRE scale to talk about, interpret and adjust some of the most important characteristics of video (brightness and sync).

We never really talk about it in these terms, but +100 IRE (the upper limit of NTSC’s “broadcast range”, essentially “white”) is equivalent to 700 millivolts (0.7 V). We *could* just use volts/millivolts to talk about video signal, but the IRE scale was designed to be more directly illustrative about data points important to analog video. Think of it this way: what number is easier to remember, 100 or 700?

Only one of those numbers has an emoji, is all I’m saying.

Audio engineers had the same conundrum when it came to analog audio signal. Where it gets super confusing from here is that many scales emerged to translate voltage into something useful for measuring audio. I think the best way to proceed from here is just to break down the various scales you might see and the context for/behind them.


Decibel-based scales are logarithmic rather than linear, which makes them ideal for measuring audio signals and vibrations – the human ear is more sensitive to certain changes in frequency and/or amplitude than others, and a logarithmic scale can better account for that (quite similar to gamma correction when it comes to color/luminance and the human eye).


The problem is that decibels are also a relative unit of measurement: something can not just be “1 dB” or “1000 dB” loud; it can only be 1 dB or 1000 dB louder than something else. So you can see quite a lot of scales related to audio that start with “dB” but then have some sort of letter serving as a suffix; this suffix specifies what “sound” or voltage or other value is serving as the reference point for that particular scale.

An extremely common decibel-based scale for measuring analog audio signals is dBu. The “u” value in there stands for an “unterminated” voltage of 0.775 volts (in other words, the value “+1 dBu” stands for an audio wave that is 1 decibel louder than the audio wave generated by a sustained voltage of 0.775 V).

In the analog world, dBu is considered a very precise unit of measurement, since it was based on electrical voltage values rather than any “sound”, which can get subjective. So you’ll see it in a lot of professional analog audio applications, including professional-grade video equipment.

Confusingly: “dBu” was originally called “dBv”, but was re-named to avoid confusion with the next unit of measurement on this list. So yes, it is very important to distinguish whether you are dealing with a lower-case “v” or upper-case “V”. If you see “dBv”, it should be completely interchangeable with “dBu” (…unless someone just wrote it incorrectly).


dBV functions much the same as dBu, except the reference value used is equivalent to exactly 1 volt (1 V). It is also used as a measurement of analog audio signal. (+1 dBV indicates an audio wave one decibel louder than the wave generated by a sustained voltage of 1 V)


Now…why do these two scales exist, referenced to slightly different voltages? Honestly, I’m still a bit mystified myself. Explanations of these reference values delve quite a bit into characteristics of electrical impedance and resistance that I don’t feel adequately prepped/informed enough to get into at the moment.

What you DO need to know is that a fair amount of consumer-grade analog audiovisual equipment was calibrated according to and uses the dBV scale instead of dBu. This will be a concern if you’re figuring out how to properly mix and match and set up equipment, but let’s table that for a minute.

PPM and VU

dBu and dBV, while intended for accurately measuring audio signal/waves, still had a substantial foot in the world of electrical signal/voltage, as I’ve shown here. Audio engineers still wanted their version of “IRE”: a reference scale and accompanying monitor/meter that was most useful and illustrative for the practical range of sound and audio signal that they tended to work with. At the time (~1930s), that meant radio broadcasting, so just keep that in mind whenever you’re flipping over your desk in frustration trying to figure out why audio calibration is the way it is.

The BBC struck in this arena first, with PPM (peak program meter), a highly accurate meter and scale intended to show “instant peaks”: the highest point on each crest of an audio wave. These meters became very popular in European broadcasting environments, but different countries and engineers couldn’t agree on what reference value, and therefore measurement scale, to use. So if you come across a PPM audio meter, you might see all kind of scales/number values depending on the context and who made it: the original BBC PPM scale went from 1 to 7, for instance (with 6 being the “intended maximum level” for radio broadcasts) while EBU PPM, ABC (American) PPM, Nordic PPM, DIN PPM, CBC PPM, etc. etc., might all show different decibel levels.


In the United States, however, audio/radio engineers decided that PPM would be too expensive to implement, and instead came up with VU meters. VU stands for Volume Units (not, as I thought myself for a long time, “voltage units”!!! VU and V are totally different units of scale/measurement).

VU meters are averaged, which means they don’t so much give a precise reading of the peaks of audio waves so much as a generalized sense of the strength of the signal. Even though this meant they might miss certain fluctuations (a very quick decibel spike on an audio wave might not fully register on a VU meter if it is brief and unsustained), this translated close enough to perceived loudness that American engineers went with this lower-cost option. VU meters (and the Volume Unit scale that accompany it) are and always have been intended to get analog audio “in the ballpark” rather than give highly accurate readings – you can see this in the incredibly bad low-level sensitivity on most VU meters (going from, say, -26 VU to -20 VU, for instance, is barely going to register a blip on your needle).

So I’ve lumped these two scales/types of meter together because you’re going to see them in similar situations (equipment for in-studio production monitoring for analog A/V), just generally varying by your geography. From here on out I will focus on VU because it is the scale I am used to dealing with as an archivist in the United States.


All of these scales I’ve described so far have related to analog audio. If the whole point of this post is to talk about digitizing analog video formats…what about digital audio?

Thankfully, digital audio is a little more straightforward, at least in that there’s pretty much only one scale to concern yourself with: dBFS (“decibels below [or in relation to] Full Scale”).

Whereas analog scales tend to use relatively “central” reference values – where ensuing audio measurements can be either higher OR lower than the “zero” point – the “Full Scale” reference refers to the point at which digital audio equipment simply will not accept any higher value. In other words, 0 dBFS is technically the highest possible point on the scale, and all other audio values can only be lower (-1 dBFS, -100 dBFS, etc. etc.), because anything higher would simply be clipped: literally, the audio wave is just cut off at that point.

Tipping the Scales

All right. dBu, dBV, dBFS, VU….I’ve thrown around a lot of acronyms and explanations here, but what does this all actually add up to?

If you take away anything from this post, remember this:

0 VU = +4 dBu = -20 dBFS

The only way to sift through all these different scales and systems – the only way to take an analog audio signal and make sure it is being translated accurately into a digital audio signal – is to calibrate them all against a trusted, known reference. In other words – we need a reference point for the reference points.

In the audio world, that is accomplished using a 1 kHz sine wave test tone. Like SMPTE color bars, the 1 kHz test tone is used to calibrate all audio equipment, whether analog or digital, to ensure that they’re all understanding an audio signal the same way, even if they’re using different numbers/scales to express it.

We worship you, o Lord our savior

In the analog world, this test tone is literally the reference point for the VU scale – so if you play a 1 kHz test tone on equipment with VU meters, it should read 0 VU. From there, the logarithms and standards demand that 0 VU is the same as +4 dBu. That is where the test tone should read if you have equipment that uses those scales.

dBFS is a *little* more tricky. It’s SMPTE-recommended practice to set 1 kHz test tone to read at -20 dBFS on digital audio meters – but this is not a hard-and-fast standard. Depending on the context, some equipment (and therefore the audio signals recorded using them) are calibrated so that a 1 kHz test tone is meant to hit -18 or even -14 dBFS, which can throw the relationship between your scales all out of whack.

(In my experience, however, 99 times out of 100 you will be fine assuming 0 VU = -20 dBFS)

Once you’re confident (relatively) that everyone’s starting in the same place, that makes it possible to proceed from there: audio signals hitting between 0 and +3 VU on VU meters, for example, should be hitting roughly between -20 dBFS and -6 dBFS on a digital scale.

Note that these are all logarithmic scales based on different logarithms – so they are never going to line up one-to-one except at the agreed-upon reference point. That is, +4 dBu may be equal to 0 VU, but +5 dBu is not equal to 1 VU. When it comes to translating audio signal from one system and scale to another, we can follow certain guidelines and ranges, but there is always going to be a certain amount of imprecision and subjectivity in working with these scales on a practical level during the digitization process.

Danger, Will Robinson

Remember when I said that we were talking about signal level, not necessarily output level, in this post? And then I said something about how professional equipment calibrated to the dBu scale versus how consumer equipment calibrated to dBV scale? Sorry. Let’s circle back to that for a minute.

Audio equipment engineers and manufacturers didn’t stop trying to cut corners when they adopted the VU meters over PPM. As a cost-saving measure for wider consumer releases, they wanted to make audio devices with ever-cheaper physical components. Cheaper components literally can’t handle as much voltage passing through them as higher-quality, “professional-grade” components and equipment.

The height of professionalism

So many consumer-grade devices were calibrated to output a 1 kHz test tone audio signal at -10 dBV, which is equivalent to a significantly lower voltage than the professional, +4 dBu standard.

(The math makes my head hurt, but you can walk through it in this post; also, I get the necessary difference in voltage but no, I still don’t really understand why this necessitated a difference in the decibel scale used)

What this means is: if you’re not careful, and you’re mixing devices that weren’t meant to work together, you can output a signal that is too strong for the input equipment to handle (professional -> consumer), or way weaker than it should be (consumer -> professional).  I’ll quote here the most important conclusion from that post I just linked above:

If you plug a +4dBu output into a -10dBV input the signal is coming in 11.79dB hotter than the gear was designed for… turn something down.

If you plug a -10dBV output into a +4dBu input the signal is coming in 11.79dB quieter than the gear was designed for… turn something up.

Unbalanced audio signal/cables are a big indicator of equipment calibrated to -10 dBV: so watch out for any audio cables and connections you’re making with RCA connectors.

Consumer-grade blogging

The reality is also that after a while many professional-grade manufacturers were aware of the -10 dBV/+4 dBu divide, and factored that into their equipment: somewhere, somehow (usually on the back of your device, perhaps on an unmarked switch) is the ability to actually swap back and forth between expecting a -10 dBV input and a +4 dBu one (thereby making any voltage gain adjustments to give you your *expected* VU/dBFS readings accordingly). Otherwise, you’ll have to figure out a way to make your voltage gain adjustments yourself.

The lessons are two-fold:

  1. Find a manual and get to know your equipment!!
  2. You can plug in consumer to professional equipment, but BE CAREFUL going professional into consumer!! It is possible to literally fry circuits by overloading them with the extra voltage and cause serious damage.

Set Phase-rs to Stun

There’s another thing to watch out for while we’re on the general topic of balanced and unbalanced audio, which are the concepts of polarity and phase.

Polarity is what makes balanced audio work; it refers to the relation of an audio signal’s position to the median line of voltage (0 V). Audio sine waves swing from positive voltage to negative voltage and vice versa -precisely inverting the polarity of a wave (i.e. taking a voltage of +0.5 V and flipping it to -0.5 V) and summing those two signals together (playing them at the same time) results in complete cancellation.

Professional audio connections (those using XLR cables/connections) take advantage of this quality of polarity to help eliminate noise from audio signals (again, you can read my post from a couple years back to learn more about that process). But this relies on audio cables and equipment being correctly wired: it’s *possible* for technicians, especially those making or working with custom setups, to accidentally solder a wire such that the “negative” wire on an XLR connector leads to a “positive” input on a deck or vice versa.

This would result in all kinds of insanely incorrectly-recorded signals, and  probably caught very quickly. But it’s a thing to possibly watch out for – and if you’re handed an analog video tape where the audio was somehow recorded with inverse polarity, there are often options (both on analog equipment or in digital audio software, depending on what you have on hand) that are as easy as flipping a switch or button, rather than having to custom solder wires to match the original misalignment of the recording equipment.

This is where phase might come into play, though. Phase is, essentially, a delay of audio signal. It’s expressed in terms of relation to the starting point of the original audio sine wave: e.g. a 90 degree phase shift would result in a quarter-rotation, or a delay of a quarter of a wavelength.

In my experience, phase doesn’t come too much into play when digitizing audio – except that a 180 degree phase shift can, inconveniently, look precisely the same as a polarity inversion when looking at an audio waveform. This has led to some sloppy labeling and nomenclature in audio equipment, meaning that you may see settings on either analog or digital equipment that refer to “reversing the phase” when what they actually do is reverse the polarity.

You can read a bit more here about the distinction between the two, including what “phase shifts” really mean in audio terms, but the lesson here is to watch your waveforms and be careful of what your audio settings are actually doing to the signal, regardless of how they’re labelled.

Reading Your Audio

I’ve referred to a few tools for watching and “reading” the characteristics of audio we’ve been discussing. For clarity’s sake, in this section I’ll review exactly, for practical purposes, what tools and monitors you can look at to keep track of your audio.

Level Meters

Level meters are crucial to measuring signal level and will be where you see scales such as dBu, dBFS, VU, etc. In both analog and digital form, they’re often handily color-coded; so if after all of this, you still don’t really get the difference between dBu and dBFS, to some degree it doesn’t matter: level meters will warn you when levels are getting too hot by changing from green to yellow and eventually to red when you’re in danger of getting too “hot” and clipping (whatever that equivalent point is in the scale in question).


Waveforms will actually chart the shape of an audio wave; they’re basically a graph with time on the x-axis and amplitude (usually measured in voltage) on the y-axis. These are usually great for post-digitization quality control work, since they give an idea of audio levels not just in any one given moment but over the whole length of the recording. That can alert you to issues like noise in the signal (if, say, the waveform stays high where you would expect more fluctuation in a recording that alternates loud and quiet sections) or unwanted shifts in polarity.

Waveform monitors can sometimes come in the form of oscilloscopes: these are essentially the same device, in terms of showing the user the “shape” of the audio signal (the amplitude of the wave based on voltage). Oscilloscopes tend to be more of a “live” form of monitoring, like level meters – that is, they function moment-to-moment and require the audio to be actively playing to show you anything. Digital waveform monitors tend to actually save/track themselves over time to give the full shape of the recording/signal, rather than just the wave at any one given moment.


Spectrograms help with a quality of audio that we haven’t really gotten to yet: frequency. Like waveforms, they are a graph with time on the x-axis, but instead of amplitude they chart audio wave frequency.

If amplitude is perceived by human ears as loudness, frequency is perceived as pitch. They end up looking something like a “heat map” of an audio signal – stronger frequencies in the recording show up “brighter” on a spectrogram.

Spectrograms are crucial to audio engineers for crafting and recording new signals, “cleaning up” audio signals by removing unwanted frequencies. As archivists, you’re probably not actually looking to mess or change with the frequencies in your recorded signal, but they can be helpful for checking and controlling your equipment; that is, making sure that you’re not introducing any new noise into the audio signal in the process of digitization. Certain frequencies can be dead giveaways for electrical hum, for example.

The More You Know

This is all a lot to sift through. I hope this post clarifies a few things – at the very least, why so much of the language around digitizing audio, and especially digitizing audio for video, is so muddled.

I’ll leave off with a few general tips and resources:

  • Get to know your equipment. Test audio reference signals as they pass through different combinations of devices to get an idea what (if anything) each is doing to your signal. The better you know your “default” position, the more confidently you can move forward with analyzing and reading individual recordings.
  • Get to know your meters. Which one of the scales I mentioned are they using? What does that tell you? If you have both analog and digital meters (which would be ideal), how do they relate as you move from one to the other?
  • Leave “headroom”. This is the general concept in audio engineering of adjusting voltage/gain/amplitude so that you can be confident there is space between the top of your audio waveform and “clipping” level (wherever that is). For digitization purposes, if you’re ever in doubt about where your levels should be, push it down and leave more headroom. If the choice is between capturing the accurate shape of an audio signal, albeit too “low”, there will be opportunity to readjust that signal again later as long as you got all the information. If you clip when digitizing, that’s it – you’re not getting that signal information back and you’re not going to be able to adjust it.

“What is the difference between level, volume and loudness?”, David Mellor

“What is the difference between dBFS, VU and dBU [sic] in Audio Recordings?”, Emerson Maningo

“Understanding & Measuring Digital Audio Levels”, Glen Kropuenske

“Audio” error entries on the AV Artifact Atlas

Everyday Linux

A couple weeks ago, there was a Forbes article that caught my eye. (No, librarians, it wasn’t that twaddle, please don’t hurt me)

No, it was this one, relating one writer/podcaster’s decision to switch to Linux as his everyday operating system after a few too many of the new “Blue Screen of Death”: Windows 10’s staggeringly inconvenient and endless Update screens.

Actually, turn it on, turn it off, who cares! You’re not working on that spreadsheet today anyway.

The article stood out because I had already been planning to write something extremely similar myself. A couple years ago, I needed a new laptop and decided I wanted out of the Apple ecosystem, partly because Apple’s desktop/laptop hardware and macOS design seemed increasingly shunted to the side in favor of iOS/mobile/tablets, but mostly because of $$$. I considered jumping ship to a Windows 10 machine, which, as I’ve said on several occasions, is actually a pretty nifty OS at its core – but, like Mr. Evangelho, I had encountered one too many productivity-destroying updates to my liking on my Windows station at work. Never mind the intrusive privacy defaults and the insane inability to permanently uninstall Candy Crush, Minecraft and other bloatware forced upon me by Microsoft.


I had used Linux operating systems, particularly Ubuntu (via BitCurator) before, and thought it might be time to take the leap to everyday use. After a little bit of research to make sure I would still be able to find versions of my most common/critical applications, I jumped ship and haven’t looked back. So, whereas I have written before about Linux in a professional context for digital preservation on several occasions, I want to finally make my evangelizing case of Linux as an everyday, personal operating system – for anyone.

Linux has a reputation as a “geeky” system for programmers and hardcore computer tinkerers, but it’s become incredibly accessible to anyone – or at least, certainly to anyone who’s used to having macOS or Windows in their daily lives. In fact, you’re almost certainly already using Linux even if you don’t realize it – if you have an Android smartphone, if you have a Chromebook laptop, if you have any of a thousand different smart/networked home devices (which, please throw them in the trash, but whatever), you’re using and relying on Linux.

Breaking away from the Mac/Windows dichotomy is as easy as your original choice of one or the other – the hurdle is largely just realizing there’s another option to debate.

Why Linux?

A Linux operating system is an example of free and open source software, often abbreviated FOSS. The “free” in there is meant to refer to “freedom”, not price (although FOSS tends to be free in that sense as well) – a legacy of the Free Software Foundation‘s four maxims that computer users should be able to:

  • run a program
  • study a program’s source code (in essence, to understand exactly how it works)
  • redistribute exact copies of that program
  • create and distribute modified versions of that program

This is all in opposition to closed and proprietary software, which use copyright and patent licenses to run contrary to at least one or more of these ideas. (Note that some open source software may still carry licenses that restrict the latter two points in certain ways – always check!)

Look, I could go on my anti-capitalist screed here, but you should probably just go see a more clever and entertaining one. But what it comes down to is that, unlike the proprietary model of one company hiring employees to build and distribute/sell its own, closed software, open source software is built by collaborative networks of programmers and users, under the general philosophy that humanity tends to make better, more broadly applicable advancements when everyone stands to (at least potentially) benefit.

Laika believed in this, don’t you?

That doesn’t mean that all open source developers are noble self-sacrificing volunteers. There are entire companies – like Canonical, Mozilla, Red Hat – dedicated to creating and supporting it, and any number of name-brand tech giants – Google, Oracle, yes Microsoft and Apple even – that at least participate in certain open source projects. When I say everyone can benefit, that often includes Big Tech. So don’t get me wrong, there’s plenty of ways to participate in and advocate for FOSS in ways that don’t involve a total shift in your operating system and computing environment, if you’re perfectly content where you are now.

But for me, switching over completely to a FOSS operating system in Linux felt like a way to take back some control from increasingly intrusive devices. For many years, Apple products’ big selling point was “it just works”, and I solidly felt that way with my first couple MacBooks – buy a laptop and the operating system got out of the way, letting you browse the internet, make movies, write up Sticky Note reminders, listen to music, and install other favorite programs and games, in a matter of minutes. I could do whatever it was I wanted to do.

I don’t feel like macOS (or Windows) “just works” quite in that same way anymore – they’re designed to work the way Apple and Microsoft want me to work. Constant, barraging notifications to log in to iCloud or OneDrive accounts, to enable Siri or Cortana AI assistance. Obscured telemetry settings sending data back to the hivemind and downloading “helpful” background programs, clogging up the computer’s resources without user knowledge. Stepping way beyond security concerns to slowly but surely cordon off anything downloaded by the user, to pigeonhole them into corporately-vetted App Stores. A six-month long hooplah over “Dark Mode.”

…go away forever?

(Look, I’m no fool – Apple’s choices were always business choices, made to ultimately improve their company’s market share, no matter which way you slice it – but I don’t think I’m alone in feeling that for some time that meant ceding at least the illusion of control to the user, or at least not nagging them every damn day into the feeling they were somehow using their own computer the “wrong” way)

Linux operating systems, because they are open and modifiable, are also extremely flexible and controllable – if that means you want to get into the nitty-gritty and install every single piece of software that makes a computer work yourself, go for it. But if that means you just want something that gets out of the way and lets you play Oregon Trail on the Internet Archive, Linux can also be that. It can be your everyday, bread-and-butter, “just works” computer, without voices constantly shouting at you about what that should look like.

What’s different?

Well, despite the whole stirring case I may have just made…there is no “Linux operating system.” Or at least, there is no one thing called “Linux” that you just go out and download and start streaming Netflix on.

Linux is a kernel. It’s the very center, core, most important piece of an operating system, but it’s not entirely functional in and of itself. You have to pile a bunch of other things on top of it: a desktop environment, a way to install and update applications, icons and windows and buttons – all the sexy, front-facing stuff that most of us actually consider when picking which operating system we want to use. So many, many, many people and companies have created their own version of that stuff, piled it on top of Linux, and released it as their own operating system. And each one of those can have a completely different look or feel to them.

All these different flavors or versions of Linux are referred to as distributions. (If you want to really fit in, call them “distros“)

So….what distribution do you choose???

This is absolutely the most overwhelming thing about switching to Linux. There are a lot of distributions, and they all have their own advantages and disadvantages – sometimes not very obvious, because there aren’t necessarily whole marketing teams behind them to give you the quick, summarized pitch on what makes their distribution different from others.

I’ve tried out several myself and will give out some recommendations, in what I hope are user-friendly terms, in the next/last section. This huge amount of choice at this very first stage can be staggering, but consider the benefit compared to closed systems: do you ever wish macOS had a “home” button and a super-key like Windows, so you could just pull up applications and more without having to remember the keyboard shortcut for Spotlight? Do you wish the Windows dock was more responsive, or its drop-down menus were located all the way at the top of the screen so you had more space for your word document? You’re probably never going to be able to make those tweaks unless Apple or Microsoft make them for you. With Linux, you can find the distribution that either already mixes and matches things the right way for you – or lets you tweak them yourself!

Like literally entire applications dedicated to easily tweaking the system

In terms of hardware, if you’re coming from Windows/PC-land, there’s not going to be much difference at all. Like Windows, you install a Linux operating system on a third-party hardware manufacturer’s device: HP, IBM, Lenovo, etc. You can competitively price features to your liking – more or less storage, higher resolution screen, higher quality keyboard or trackpad, whatever it is that’s important to you and your everyday comfort.

A small handful of companies will even directly sell you laptops with Linux distributions pre-installed (System76, Dell). But for the most competitive (read: cheapest) options, you’ll have to install Linux on a PC of your choice yourself.

Maybe not the most efficient choice

Like with Windows, this does also mean you *may* occasionally have to install or reinstall drivers to make certain peripheral devices (Wi-Fi cards, external mice) play nice with your operating system. This used to be a much more common issue than it is now, and a legitimate knock against Linux systems – but these days, if you’re using a major, well-supported distribution, it’s really no worse than Windows. And if you’re sitting there, a dedicated Windows user, thinking “huh, I’ve never had to deal with that”, neither have I in two years on my Linux laptop. This is more a warning to the Mac crowd that, hey, it’s possible for problems to arise when the company making the software isn’t also making the hardware (and if you’ve ever used a cheap non-Apple Thunderbolt adapter  or power charger – you probably knew that anyway!)

Finally, applications! Again, the major Linux distributions have all at this point pretty much borrowed the visual conception of the “App Store” – a program you can use to easily browse, install and launch a vast range of open source software. The vetting may not be as thorough – so bring the same healthy dose of skepticism and awareness that you do to the Google Play Store and you’ll be fine.

Sure, “contains ads”, seems legit

If you’re worried about losing out on your favorite Mac/Windows programs, you absolutely may want to do some research to make sure there are either Linux versions or at least satisfactory Linux equivalents to the software you need. But while you might not be able to get Adobe programs, for instance, on to your new operating system, there’s plenty of big-name proprietary apps that have made the leap in recent years: Spotify, Slack, even Skype. And Linux programs are usually available to at least open and convert the files you originally made with their Mac/Windows equivalents (LibreOffice can open and work with the various Microsoft Office formats, for instance, and GIMP can at least partially convert PhotoShop .PSDs)

Installing these applications is as easy as clicking “Install” in an App Store. No Apple ID hoops to go through. And the really wonderful thing is that unlike Mac or Windows, most Linux systems will track and perform application updates at the same time and in the same place as operating system updates – no more menu-searching and notifications from individual applications to make sure you’re on the latest, greatest, and most secure version of any given program. You’ll just get a general pop-up from the “Software Center” or equivalent and perform updates in one quick, fell swoop, or as nit-picky as desired. (And my Linux laptop has never unexpectedly forced a restart to update while I was doing something else)

And finally, Linux drives are formatted differently than macOS or Windows, using the “ext4” file system. This means you can encounter some of the same quirks in moving your old files to a Linux system that you’ve ever had in shuttling between Mac and Windows – but Linux pretty much always comes with at least read support for HFS+ (Mac) and NTFS (Windows) drives, so likewise I’ve never had issues with at least just transferring old files over to a new drive.

How can I try it out?

The great news is, unlike Mac or Windows, you don’t have to go to a physical store or buy a completely new laptop just to try a Linux distribution and see if it’s something you would like to use!

Just like when you install (or reinstall) the operating system on a Mac or Windows computer, to install Linux you’ll need a USB drive that is at least 8GB large to house the installation disk image – an ISO file. Unlike Mac or Windows, Linux installation images, in addition to the installation program itself, pretty much always have a “Live” mode – this lets you run a Linux session on your computer, to see how well it works on your hardware and if you like the distribution’s design and features. It’s a fantastic try-before-you-buy feature, and can even work with MacBooks, if that’s all you have (just don’t be surprised/blame Linux if there’s some hardware wonkiness, like your keyboard not responding 100% correctly).

Once you have an 8GB USB flash drive and the ISO file for the OS you want to try downloaded, you’ll need an application to “burn” the ISO to the flash drive and make it bootable. I recommend Etcher, which is multi-platform so it’ll work whether you’re starting out on Mac or Windows (and also, just for the record, if you’re trying to make bootable installers from macOS .DMGs or Windows ISOs – Etcher is a rad tool!). From there you’ll need to boot into the installer USB according to instructions that will depend on your laptop manufacturer (it usually means holding down one of the function keys at the top of your keyboard during startup, but the key combination varies depending on the hardware/maker).

So what about all those distributions? Which ones should you try? Here are some of the most popular flavors that I think would also be accessible to converts making their way over from macOS or Windows. These distributions all have wide user bases, meaning they all have either good documentation or even active support accounts that you can contact in the event of questions or problems.


Thanks to its popularity as an operating system for servers and the Internet of Things, Ubuntu is probably the biggest name in Linux, and if you just want a super stable, incredibly well-supported desktop with thoughtful features, it is still my go-to recommendation for most casual users seeking alternative to macOS and Windows (and as I said earlier, if you’ve ever encountered BitCurator, you already know what it looks/feels like). It’s what I use myself for day-to-day web browsing, streaming services, word processing, some Steam gaming, light digipres/coding and a bit of server maintenance for this very site.

When it comes to Ubuntu, you’re going to want to look to try out a version labeled “LTS” – that’s “Long-Term Support”, meaning OS updates are guaranteed for five years (any of the other versions are primarily for developers and other anxious early adopters who don’t mind a few more bugs). The latest LTS release, 18.04, just came out a couple months ago with a pretty major desktop redesign, but it’s as attractive, sleek and functional as ever, and I came back to it after flirting with some of the other distributions on this list.

Linux Mint

Linux Mint is itself a derivative of Ubuntu, so everything I just said about stability and support goes for Mint as well – the Mint developers just wait for Ubuntu to release updates and then add their own spin. The differences are thus largely visual – Linux Mint’s desktop is made to look more like Windows, so users who are migrating from that direction are more likely to be at home here. It’s been around for a while so the support community is likewise large and varied.


Zorin is also an Ubuntu derivative that’s even more explicitly targeted at converting Windows users/Linux newbies. It’s newer than Mint but I have to say personally I think that’s led to a fresher, more attractive design. (More Windows 10 to Linux Mint’s Windows 7). In fact it’s pretty much built around flexible, easily changed desktop design. Going with a distribution based on super pretty icons and easily swapping around menus might seem silly, but honestly, there’s so many distributions with such similar core features that these *are* the kinds of decisions that make Linux users go with one over the other.

elementary OS

Whereas Linux Mint and Zorin are more or less “Ubuntu for Windows converts”, elementary OS has a visual design more targeted to bring over macOS users, with a dock, top menu bar, etc. It’s a very light, sleek OS that really only ships with the most basic apps and the design encourages you to keep things simple (their media apps are literally just called things like “Music” and “Videos”, and their custom web browser Epiphany has a bare minimum of features to keep from becoming a memory hog like Firefox and Chrome). But since it’s Ubuntu based you can still easily install more familiar open source apps like VLC, etc. Also a very intriguing Linux OS to try if you’re used to something like a Chromebook or a tablet as your primary device.


System76 is known more for their attractive hardware and great customer support (I’ve had my Lemur for two years and am still in love), but they recently tried putting out their own Ubuntu Linux distribution targeted at developers and creative professionals. It pretty much seems like Ubuntu but with some more minimalist icon design and some nifty expanded features for multiple workspaces, but mostly I’m plugging them here because if you wind up looking for higher-end hardware and some really helpful, responsive support, System76 is tops.


Whereas all these previous distributions I’ve mentioned have built off the stability of Ubuntu, Solus is different, as it is its own completely independent OS. It’s an example of a “rolling release” operating system: while with macOS, Windows, and many Linux distributions like Ubuntu, you have to worry about your particular, fixed-point version eventually becoming obsolete and no longer receiving updates (e.g. once macOS 10.14 comes out, those users still using 10.11 will no longer receive security and software updates from Apple), Solus will just continually roll out updates, forever. Or, well, “forever,” but you get what I mean.

That means users actually get the latest software and features much faster, as you don’t have to wait for those things to get bundled into the next “release”. It’s an interesting model if you’re really ready to unmoor and explore away from the usual systems.

Aside from that, Solus’ custom “Budgie” desktop design is extremely pretty and modern, with a quick-launch menu and a custom applets bar. It feels a lot like Windows 10 in that sense.

Color is Math

I know, I hate to break it to you. I’m not thrilled about it either – one of my favorite memories from high school is walking straight up to my Statistics teacher on the last day of senior year and proudly announcing that it was the last time I was ever going to be in a math class. (Yes, I do feel a bit guilty about the look of befuddled disappointment on his face, but by god I was right)

But it’s true: at least when it comes to video preservation, color is math. Everything else you thought you knew about color – that it’s light, that you get colors by mixing together other colors, that it’s pretty – is irrelevant.


Just now, you thought you were looking at color bars? Wrong. Numbers.


When I first started learning to digitize analog video, the concept of luminance and brightness made sense. Waveform monitors made sense. A bright spot in a frame of video shows up as a spike on the waveform in way that appeases visual logic. When digitizing, you wanted to keep images from becoming too bright or too dark, lest visual details at these extremes be lost in the digital realm. All told, pretty straightforward.

Vectorscopes and chrominance/color information made less sense. There were too many layers of abstraction, and not just in “reading” the vectorscope and translating it to what I was seeing on the screen – there was something about the vocabulary around color and color spaces, full of ill-explained and overlapping acronyms (as I have learned, the only people who love their acronyms more than moving image archivists and metadata specialists are video engineers).

I’d like to sift through some of the concepts, redundancies, and labeling/terminology that threw me off personally for a long time when it came to color.


Who in the rainbow can draw the line where the violet tint ends and the orange tint begins? Distinctly we see the difference of the colors, but where exactly does the one first blendingly enter into the other? So with sanity and insanity.

Herman Melville, Billy Budd

I think it might help if we start very very broad in thinking about color before narrowing in on interpreting color information in the specific context of video.

In the early 20th century, color scientists attempted to define quantitative links between the visible spectrum of electromagnetic wavelengths and the physiological perception of the human eye. In other words – in the name of science, they wanted to standardize the color “red” (and all the other ones too I guess)

Though we all know it’s the best one, right

Given the insanely subjective process of assigning names to colors, how do you make sure that what you and I (or more importantly, two electronics manufacturers) call “red” is the same? By assigning an objective system of numbers/values to define what is “red” – and orange, yellow, green, etc. etc. – based on how light hits and is interpreted by the human eye.

After a number of experiments in the 1920s, the International Commission on Illumination (abbreviated CIE from the French – like FIAF) developed in 1931 what is called the CIE XYZ color space: a mathematical definition of, in theory, all color visible to the human eye. The “X”, “Y” and “Z” stand for specific things that are not “colors” exactly, so I don’t even want to get into that here.

The important thing about the CIE XYZ color space – you can’t really “see” it. The limitations of image reproduction technology mean there will always be tangible limits standing between you and the full CIE XYZ gamut (outside of, maybe, a color scientist’s lab, but I’m not even convinced of that). Consider that graph above: even though it’s colored in for illustrative purposes, that’s not actually every color you can possibly see in there. The actual wavelengths of light produced, and therefore colors represented, by your computer’s LED screen encompasses a much much more limited range of values.

tl;dr your computer screen, compared to the mathematical limits of the natural world – sucks.

That’s to be expected though! Practical implementations of any standard will always be more limited than an abstract model.


So even if it basically only exists in theory (and in the unbounded natural world around us), the CIE XYZ color space and its definition of color values served as the foundation for most color spaces that followed it. A color space is the system for creating/reproducing color employed by any particular piece of technology. Modern color printers, for example, use the CMYK color space: a combination of four color primaries (cyan, magenta, yellow, and “key”/black) that when mixed together by certain, defined amounts, create other colors, until you have hard copies of your beautiful PowerPoint presentation ready to distribute.

Again, just like CIE XYZ, any color space you encounter is math – it’s just a method of saying this number means orange and this number means blue and this number means taupe. But, just like with all other kinds of math, color math rarely stays that straightforward. The way each color space works, the way its values are calculated, and the gamut it can cover largely depend on the vagaries and specific limitations of the piece of technology it’s being employed with/on. In the case of CIE XYZ, it’s the human eye – in the case of CMYK, it’s those shitty ink cartridges on your desktop laser printer that are somehow empty again even though you JUST replaced them.

More lying liars who lie

So what about analog video? What are the specific limitations there?

Peak TV: Color in Analog Video

Video signals and engineering are linked pretty inextricably with the history of television broadcasting, the first “mass-market” application of video recording.

So tune in to what you know of television history. Much like with film, it started with black-and-white images only, right? That’s because it’s not just budding moving image archivists who find brightness easier to understand and manipulate in their practical work – it was the same for the engineers figuring out how to create, record, and broadcast a composite video signal. It’s much easier for a video signal to tell the electron gun in a CRT television monitor what to do if frame-by-frame it’s only working with one variable: “OK, be kinda bright here, now REALLY BRIGHT here, now sorta bright, now not bright at all”, etc.

Compare that to: “OK, now display this calculated sum of three nonlinear tristumulus primary component values, now calculate it again, and again, and oh please do this just as fast when we just gave you the brightness information you needed”.

So in first rolling out their phenomenal, game-changing new technology, television engineers and companies were fine with “just” creating and sending out black-and-white signals. (Color film was only just starting to get commonplace anyway, so it’s not like moving image producers and consumers were clamoring for more – yet!)

Who needs color video when you have these two, said America

But as we moved into the early 1950s, video engineers and manufacturing companies needed to push their tech forward (capitalism, competition, spirit of progress, yadda yadda), with color signal. But consider this – now, not only did they need to figure out how to create a color video signal, they needed to do it while staying compatible with the entire system and market of black-and-white broadcasting. The broadcast companies and the showmakers and the government regulation bodies and the consumers who bought TVs and everyone else who JUST got this massive network of antennas and cables and frequencies and television sets in place were not going to be psyched to re-do the entire thing only a few years later to get color images. Color video signal needed to work on televisions that had been designed for black-and-white.

From the CIE research of the ’20s and ’30s, video engineers knew that both the most efficient and wide-ranging (in terms of gamut of colors covered) practical color spaces were composed by mixing values based on primaries of red, green, and blue (RGB).

No no no no notorious

But in a pure RGB color space, brightness values are not contained on just one component, like in composite black-and-white video – each of the three primary values is a combination of both chrominance and luminance (e.g. the R value is a sum of two other values that mean “how red is this” and “how bright is this”, respectively). If you used such a system for composite analog video, what would happen if you piped that signal into a black-and-white television monitor, designed to only see and interpret one component, luminance? You probably would’ve gotten a weirdly dim and distorted image, if you got anything at all, as the monitor tried to interpret numbers containing both brightness and color as just brightness.

This is where differential color systems came into play. What engineers found is that you could still create a color composite video signal from three component primaries – but instead of those being chrominance/luminance-mixed RGB values, you could keep the brightness value for each video frame isolated in its own Y′ component (which Charles Poynton would insist I now call luma, for reasons of…..math), while all the new chroma/color information could be contained in two channels instead of three: a blue-difference (B′-Y′) and a red-difference (R′-Y′) component. By knowing these three primaries, you can actually recreate four values: brightness (luma) plus three chroma values (R, G, and B). Even though there’s strictly speaking no “green” value specified in the signal, a color television monitor can figure out what this fourth value should be based on those differential calculations.

For television broadcasting, keeping the luma component isolated meant that you could still pipe a color composite video signal into a black-and-white TV, and it would still just display a correct black-and-white image: it  just used the values from the luma component and discarded the two color difference components. Meanwhile, new monitors designed to interpret all three components correctly would display a proper color image.

This basic model of using two color difference components for video was so wildly efficient and successful that we still use color spaces based on this model today! Even as we passed from analog video signals into digital.

Making it possible with adapters and converters, to, say, play Fallout 4 on a B&W TV

Lookup Table: “YUV”

…but you may have noticed that I just said “basic model” and “color spaces”, as in plural. Uh oh.

As if this wasn’t all complicated enough, video engineers still couldn’t all just agree on one way to implement the Y′, B′-Y′, R′-Y′ model. Engineers working within the NTSC video standard needed something different than those working with PAL, who needed something different than SECAM. The invention of component video signal, where these three primaries were each carried on their own signal/cable, rather than mixed together in a single, composite signal, also required new adjustments. And digital video introduced even more opportunities for sophisticated color display.

I mean just look at this gamut

So you got a whole ton of related color spaces, each using the same color difference model, but employing different math to get there. In each case, the “scale factors” of the two color difference signals are adjusted to optimize the color space for the particular recording technology or signal in question. Even though they *always* basically represent blue-difference and red-difference components, the letters change because the math behind them is slightly different.

So here is a quick guide to some common blue/red difference color spaces, and the specific video signal/context they have been employed with:

  • Y′UV = Composite analog PAL video
  • Y′IQ = Composite analog NTSC video
  • Y′DBDR = Composite analog SECAM video
  • Y′PBPR = Component analog video
  • Y′CBCR = Component digital video – intended as digital equivalent/conversion of YPBPR, and also sometimes called “YCC”
  • PhotoYCC (Y′C1C2) = Kodak-developed digital color space intended to replicate the gamut of film on CD; mostly for still images, but could be encountered with film scans (whereas most still image color spaces are fully RGB rather than color-difference!)
  • xvYCC = component digital video, intended to take advantage of post-CRT screens (still relatively rare compared to Y′CBCR, though), sometimes called “x.v. Color” or “Extended-gamut YCC”

And now a PSA for all those out there who use ffmpeg or anyone who’s heard/seen the phrase “uncompressed YUV” or similar when looking at recommendations for digitizing analog video. You might be confused at this point: according to the table above, why are we making a “YUV” file in a context where PAL video might not be involved at all???

As Charles Poynton again helpfully lays out in this really must-read piece – it literally comes down to sloppy naming conventions. For whatever reason, the phrase “YUV” has now loosely been applied, particularly in the realm of digital video and images, to pretty much any color space that uses the general B′-Y′ and R′-Y′ color difference model.

I don’t know the reasons for this. Is it because Y′UV came first? Is it because, as Poynton lays out, certain pieces of early digital video software used “.yuv” as a file extension? Is it a peculiar Euro-centric bias in the history of computing? The comments below are open for your best conspiracy theories.

By which I mean Kirov conspiracy theories or GTFO

I don’t know the answer, but I know that in the vast vast majority of cases where you see “YUV” in a digital context – ffmpeg, Blackmagic, any other kind of video capture software – that video/file almost certainly actually uses the Y′CBCR color space.

Gamma Correction, Or How I Learned To Stop Worrying and Make a Keyboard Shortcut for “Prime”

Another thing that I must clarify at this point. As evidenced by this “YUV” debacle, some people are really picky about color space terminology and others are not. For the purposes of this piece, I have been really picky, because for backtracking through this history it’s easier to understand precise definitions and then enumerate the ways people have gotten sloppy. You have to learn to write longhand before shorthand.

So you may have noticed that I’ve been picky about using proper, capitalized subscripts in naming color spaces like Y′CBCR. In their rush to write hasty, mean-spirited posts on the Adobe forums, you may see people write things like “YCbCr” or “Y Cb Cr” or “YCC” or any other combination of things. They’re all trying to say the same thing, but they basically can’t be bothered to find or set the subscript shortcuts on their keyboard.

which, I mean, I don’t entirely blame ’em

In the same vein, you may have noticed these tiny tick marks (′) next to the various color space components I’ve described. That is not a mistake nor an error in your browser’s character rendering nor a spot on your screen (I hope). Nor is it any of the following things: an apostrophe, a single quotation mark, or an accent mark.

This little ′ is a prime. In this context it indicates that the luma or chroma value in question has been gamma-corrected. The issue is – you guessed it – math.

Curse you, Mathemagician

The human eye perceives brightness in a nonlinear fashion. Let’s say the number “0” is the darkest thing you can possibly see and “10” is the brightest. If you started stepping up from zero in precisely regular increments, e.g. 1, 2, 3, 4, etc., all the way up to ten, your eyes would weirdly not perceive these changes in brightness in a straight linear fashion – that is, you would *think* that some of the increases were more or less drastic than the others, even though mathemetically speaking they were all exactly the same. Your eyes are just more sensitive to certain parts of the spectrum.

Gamma correction adjusts for this discrepancy between nonlinear human perception and the kind of linear mathematical scale that technology like analog video cameras or computers tend to work best with. Don’t ask me how it does that – I took Statistics, not Calculus.

The point is, these color spaces adjust their luma values to account for this, and that’s what the symbol indicates. It’s pretty important – but then again, prime symbols are usually not a readily-accessible shortcut that people have figured out on their keyboards. So they just skip them and write things like… “YUV”. And I’m not just talking hasty forum posts at this point – I double-dare you to try and reconstruct everything I’ve just told you about color spaces from Wikipedia.

Which, come to think of it, the reason why “YUV” won out as a shorthand term for Y′CBCR may very well be just that it doesn’t involve any subscripts or primes. Never underestimate ways programmers will look to solve inefficiencies!

Reading a Vectorscope – Quick Tips

This is all phenomenal background information, but when it gets down to it, a lot of people digitizing video just want to know how to read a vectorscope so they can tell if the color in their video signal is “off”.

Here we have a standard SMPTE  NTSC color bars test pattern as it reads on a properly calibrated vectorscope. Each of the six color bars (our familiar red, green, and blue, as well as cyan, yellow, and magenta) are exactly as they should, as evidenced by the dots/points falling right into the little square boxes indicated for them (the white/gray bar should actually be the point smack in the center of the vectorscope, since it contains no chroma at all).

The saturation of the signal will be determined by how far away from the center of the vectorscope the dots for any given frame or pixel of video fall. For example, here is an oversaturated frame – the chroma values for this signal are too high, which you can tell because the dots are extending out way beyond the little labeled boxes.

Meanwhile, an undersaturated image will just appear as a clump towards the center of the vectorscope, never spiking out very far (and a black-and-white image should in fact only do that!)

Besides saturation, a vectorscope can also help you see if there is an error in phase or hue (both words refer to the same concept). As hopefully demonstrated by our discussion of color spaces and primaries, colors generally relate to each other in set ways – and the circular, wheel-like design of the vectorscope reflects that. If the dots on a vectorscope appear rotated – that is, dots that should be spiking out towards the “R”/red box, are instead headed for the “Mg”/magenta box – that indicates a phase error. In such a case, any elephants you have on screen are probably going to start all looking like pink elephants.

The problem is, even with these “objective” measurements, color remains a stubbornly subjective thing. Video errors in saturation and phase may not be so wildly obvious as the examples above, making them a tricky thing to judge, especially against artistic intent or the possibility of an original recording being made with mis-calibrated equipment. Again, you can find plenty of tutorials and opinions on the subject of color correction online from angry men, but I always just tell everyone to use your best judgement. It’s as good as anyone else’s!

XKCD #1492

(If you do want or need to adjust the color in a video signal, you’ll need a processing amplifier.)

Pixel Perfect: Further Reading on Color

I’ve touched on digital video and color here but mostly focused on pre-digital color spaces and systems for audiovisual archivists and others who work with analog video signals. Really, that’s because all of this grew out of a desire to figure out what was going on with “uncompressed YUV” codecs and “-pix_fmt yuv420p” ffmpeg flags, and I worked backwards from there until I found my answers in analog engineering.

There’s so much more to get into with color in video, but for today I think I’m going to leave you with some links to explore further.

From the master of pixels, Charles Poynton:

On the subject of chroma subsampling:

On the subject of other color spaces beyond Y′CBCR

  • openYCoCg
    An experimental video codec from AV Preservation by Reto Kromer, based on the Y′COCG color space, which can convert to/from RGB values but isn’t based on human vision models (using orange-difference and green-difference instead of the usual blue/red)
  • Digital Photography School: sRGB versus Adobe RGB
XKCD #1882