WEBVTT 00:00:00.000 --> 00:00:04.160 Have you ever noticed that after you'd upload an image to your favorite social media site, 00:00:04.160 --> 00:00:08.640 it sometimes doesn't look quite as good as you thought it would, specifically because 00:00:08.640 --> 00:00:12.000 the image was compressed or it had its resolution lowered? 00:00:12.000 --> 00:00:16.920 Well, naturally, it turns out that there are reasons that social media services do this, 00:00:16.920 --> 00:00:22.000 as it's crucial for helping them manage the millions of images our selfie addicted society 00:00:22.000 --> 00:00:28.560 is uploading every day. So how exactly do these large services get images to us quickly, and how are they making 00:00:28.560 --> 00:00:32.960 improvements to try and keep the image quality as high as they can? 00:00:32.960 --> 00:00:37.440 To answer that, we spoke with Nolan O'Brien at Twitter, and we'd like to thank him both 00:00:37.440 --> 00:00:41.520 personally as well as Twitter itself for help with this episode. 00:00:41.520 --> 00:00:46.320 Large services like Twitter face enormous challenges trying to get images to so many 00:00:46.320 --> 00:00:52.880 different users. The images that go through Twitter's servers every day number in the billions with a B, 00:00:52.880 --> 00:00:58.400 and they have to figure out how to quickly get them to their 330 million users, even 00:00:58.400 --> 00:01:06.800 if those users are far away from Twitter's data centers. A large part of the solution is using content delivery networks, or CDNs, which are distributed 00:01:06.800 --> 00:01:14.400 storage networks that you can learn more about here. This way, devices will have a semi-nearby server to pull images from. 00:01:14.400 --> 00:01:19.760 But what about the images themselves? Well, Twitter uses both PNG and JPEG images. 00:01:19.760 --> 00:01:24.360 Both are compressed, which saves bandwidth compared to using huge uncompressed images 00:01:24.360 --> 00:01:28.840 that can easily take up around 35 megabytes if shot with a typical smartphone camera. 00:01:28.840 --> 00:01:34.280 However, PNGs use lossless compression, meaning their higher quality but take up significantly 00:01:34.280 --> 00:01:41.920 more space than a JPEG. Typically, Twitter will convert most images to JPEG if the PNG version has a high color 00:01:41.920 --> 00:01:47.440 depth, meaning that if they support 16-bit or a little over 65,000 colors, which actually 00:01:47.440 --> 00:01:52.160 isn't all that many considering modern displays support millions of colors. 00:01:52.160 --> 00:01:56.960 Additionally, JPEGs that take up more than 5 megabytes are also reduced in quality. 00:01:56.960 --> 00:02:01.560 But hold on a second, I use Twitter all the time and I think the images look pretty decent. 00:02:01.560 --> 00:02:04.600 How do they pull that off using so much compression? 00:02:04.600 --> 00:02:11.400 Keep in mind that Twitter still supports JPEGs up to about 16.7 megapixels, or about 4.2 megapixels 00:02:11.400 --> 00:02:19.840 if you're uploading from mobile. And when this service has to reduce to JPEG quality, it does so by only about 15%. 00:02:19.840 --> 00:02:24.880 Typically such a loss in quality isn't noticeable unless you're looking very closely, yet still 00:02:24.880 --> 00:02:31.760 saves a significant amount of bandwidth. And this is especially true since phone screens these days are very high resolution, yet small 00:02:31.760 --> 00:02:36.840 in size, so images can very easily be scaled down in resolution without a noticeable loss 00:02:36.840 --> 00:02:42.400 in visual fidelity. Many phone screens only have one red or blue pixel for every green, so trying to show a 00:02:42.480 --> 00:02:46.800 super high resolution photo on them would be a waste, as the phones can't even reproduce 00:02:46.800 --> 00:02:52.960 them accurately. If you compare these images to original side by side on a high-res desktop monitor, you 00:02:52.960 --> 00:02:59.080 may notice a difference. But for phone users who are often most impacted by speed constraints, the compression methods 00:02:59.080 --> 00:03:06.520 we've mentioned so far are no-brainers. Of course, sometimes noticeable trade-offs, even on mobile devices, cannot be avoided. 00:03:06.520 --> 00:03:10.960 Many people use social media services without fast connections, so if you're on a slow 00:03:11.160 --> 00:03:16.240 connection, you might notice that Twitter uses progressive JPEGs, meaning that a low-quality 00:03:16.240 --> 00:03:21.720 version will fully load first while you wait for the higher-res version, contrasting with 00:03:21.720 --> 00:03:27.320 the slowly loading image from top down as you probably remember from the dial-up era, 00:03:27.320 --> 00:03:32.280 if you're old. Then you have to factor in how people use many different devices, including some really 00:03:32.280 --> 00:03:37.120 old ones. This is a big part of the reason you might have noticed that Twitter header images often 00:03:37.120 --> 00:03:42.600 appear to be lower quality as they're capped at 500 pixels vertically to ensure that they 00:03:42.600 --> 00:03:46.680 can be shown correctly on legacy devices. 00:03:46.680 --> 00:03:50.240 But what about all the space these pictures take up on Twitter servers? 00:03:50.240 --> 00:03:55.760 Well, it turns out that storage isn't all that difficult to expand, so the choices that 00:03:55.760 --> 00:04:01.400 social networks make with how they process images has less to do with drive capacity 00:04:01.400 --> 00:04:06.840 and more to do with how to use as little bandwidth as possible for the end user. 00:04:07.240 --> 00:04:11.640 Who has an extra five seconds to wait for the next zesty Linus meme to load? 00:04:11.640 --> 00:04:17.200 Am I right? Not me. So thanks for watching, guys. If you liked this video, give it a like, give us a subscribe, and be sure to hit us 00:04:17.200 --> 00:04:21.080 up in the comments section with your suggestions for future topics that we should cover.