Both get referred to as 2K. https://en.wikipedia.org/wiki/2K_resolution

I would prefer 2560×1440 to be called 2K5 but the industry is too comfortable with 2-letter resolutions now.

No, 1080p is 2K because its width is 1920 (close to 2000), 2160p is 4K (3840 px wide), 4320p is 8K (7680 px wide). It’s not 1K, 4K and 16K.

The town name and state is also very easy to figure out, and you can easily verify it by checking where Musk will be holding a town hall today. For each of the most violently crossed-out words, D███ and C███████, there is just one first name matching whatever is visible. Yes, I copied and pasted letters from elsewhere and the width is correct.

Greedy marketers just wanted to show a higher number… That’s why they switched from height to width, too.

By having seen a low-end 2017 laptop?

1080 rows of 1920 pixels each
1920 columns of 1080 pixels each

https://www.xkcd.com/1889/

If 2K referred to the number of pixels, it would look like this:

FullHD is actually a little over 2M pixels.

takes the aspect ratio from 3:4 to 16:9. so pixel density is barely better

What? Screen aspect ratio and pixel density are quite different things. Most FullHD TVs are widescreen and have pixel density below 36 ppi, and while high-DPI 4:3 screens are rare, they are not impossible in any way.

The terms “2K” and “4K” were totally commonplace since about 2010, although not as prevalent as 1080p. I hate how the video industry switched to marketing horizontal resolution (and rounding it up) just to make the number look big.

I know the difference but there are lots of people who aren’t really savvy with video technology. I wouldn’t blame them for thinking that ［🢐 １０８０ 🢒］ is just barely better than 1024x768.

2k and 4k does not refer to horizontal resolution but the number of pixels

Nope. 1920×1080 is 2 073 600 pixels, which would be 2M. “2K” is the horizontal resolution (1920) rounded up. A screen with literally 2K pixels would be around 50×40, lower than the crappiest handheld consoles.

Not the morning pages!! 📟💥

…and ignore one of the coolest things there is to see on the sky

A solar or lunar eclipse?

First sentence of my post, for this very reason – they own the franchise, after all. The law may also change the other way but that’s very unlikely to happen in the US within 50 years.

I wonder if they could develop a system of draconian DRM (only their own theatres with metal detectors, personalized online streams…) and mildly edit movies every few decades so that they can destroy the original and effectively renew copyright. The gaming industry’s always-online DRM makes nuking a release possible but copyright lasts for about 20 console generations (we’ve only had 8 so far!) so they don’t even have to do that.

I think that at least the sub-title “Episode IV: A New Hope” was added in that DVD release… Anyway, a “4K77” scan of a 1977 film reel distributed directly by the studio exists, it’s just noisy and needed color correction.

find an original film print and have it scanned

The 4K77 project did just that, scan and color correction to reverse fading, and effectively no other processing so they cannot claim copyright. Arguably, Harmy’s Despecialized Edition cannot either, even if the original becomes public domain, as it could be argued that their effort only served a technical purpose. I don’t think you can scan, upscale and denoise Steamboat Willie (Walt Disney, 1928) and claim copyright on that even if you do it by hand.

Interesting… Too bad a right-holder can do minor edits to their work and effectively extend copyright (which is already very long in my opinion) if they nuke the previous version. Lucas was surprisingly successful at that, and I think game studios or other creators could do that today too with their aggressive DRM tactics.

Thank you, great point!

ZJh (base64) in binary is 011001 001001 100001

I analyzed it in another comment: the header says the image is 300x300px 8-bit RGBA but the data is invalid. Most viewers will notice that and show an error.

However, the syntax it used for embedding images is valid, as data:image/png;base64, is the start of a valid image URL and you can use it like other image URLs in supported Markdown interpretors.

Example, using the 103-byte Google Maps’ sea tiles, and a 178-byte GIF:

![Google Maps sea map tile](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAEAAQMAAABmvDolAAAAA1BMVEW10NBjBBbqAAAAH0lEQVRoge3BAQ0AAADCoPdPbQ43oAAAAAAAAAAAvg0hAAABmmDh1QAAAABJRU5ErkJggg==)
![wink.gif](data:image/gif;base64,R0lGODlhDwAVAKIEAAAAAP//AP//3v///wAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFlgAEACwAAAAADwAVAAADSUiq0L2QtEDpg6Bqu/LeAGN5wVRKlVmS6qe17hiDHvlyNciho5N2sxDGtoIMBgyH8Kg4IiMEZ1NKlUarSOdTe81arZHvE3olJAAAIfkEBR4ABAAsCAAEAAQABQAAAwYIGtz+ASQAOw==)

renders as

Works in the default web interface

I prefer hexadecimal. The encoded data in its entirety is

89 50 4E 47 0D 0A 1A 0A 
00 00 00 0D 49 48 44 52 
00 00 01 2C 00 00 01 2C 
08 06 00 00 00 B9 B4 AC 
33 00 00 01 A4 49 44 41 
54 78 9C ED DD 41 8E 83 
40 10 85 E1 7F 7F E4 B2 
72 25 92 61 64 98 59 26 
16 49 85 92 61 64 98 59 
26 16 49 85 92 61 64 98 
59 26 16 49 85 92 61 64 
98 59 26 16 49 85 92 61 
64 98 59 26 16 49 85 92 
61 64 98 59 26 16 49 85 
92 61 64 98 59 26 16 49 
85 92 61 64 98 59 26 16 
49 85 92 61 64 98 59 26 
16 49 85 92 61 64 98 59 
26 16 49 85 92 61 64 98 
59 26 16 49 85 92 61 64 
98 59 26 16 49 85 92 61 
64 98 59 26 16 49 85 92 
61 64 98 59 26 16 49 85 
92 61 64 98 59 26 16 49 
85 92 61 64 98 59 26 16 
49 85 92 61 64 98 59 26 
16 49 85 92 61 64 98 59 
26 16 49 85 92 61 64 98 
59 26 16 49 85 92 61 64 
98 59 26 1(abrupt end at 4 bits of last byte)

We can analyze the PNG file header. Surprisingly, some of it makes sense.

89 50 4E 47 0D 0A 1A 0A //PNG signature (0x89 P N G 0xD 0xA 0x1A 0xA)

00 00 00 0D // Start of chunk with data length 13 bytes
49 48 44 52 // Type of chunk: IHDR (image header)
00 00 01 2C // Width: 300 px
00 00 01 2C // Height: 300 px 
08 // Bits per color channel: 8 
06 // Color format: 6 (RGBA)
00 // Compression method: 0 (DEFLATE)
00 // Filter method: 0 (Adaptive)
00 // Interlace method: 0 (None)
B9 B4 AC 33 // CRC-32 of chunk (invalid, should be 79 7D 8E 75)

00 00 01 A4 // Start of chunk with data length 420 bytes
49 44 41 54 // Type of chunk: IDAT (image data)
78 9C ED DD 41 8E 83 40 
10 85 E1 7F 7F E4 B2 72 25 
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 16 49 85
92 61 64 98 59 26 1
// 194.5 of the expected 420 data bytes, invalid when attempting to deflate
// the deflate algorithm needs a Huffman tree but an unfull one is presented

Credits to the PNG chunk inspector at nayuki.io

You may try to figure out if the header checksum was stolen from elsewhere and corresponds to another common image size but I cannot be bothered. The data could be subjected to forensic analysis but we only really have 21 unique bytes, the rest is likely nonsense because data encoded by the DEFLATE algorithm is unlikely to be so repetitive. Also, the image in total will likely have just 481 bytes (8+(8+13+4)+(8+420+4)+16), as a less-than-65535-byte IDAT chunk tends to be the last one before a 16-byte trailer. There are very few 300x300 PNGs of such small size we could call memes, most of it will have to be just solid color. Example of a 256x256 map tile you can store in around that size (467 B):

(And this one is pre-optimized, using an indexed palette of just 13 distinct RGB colors as opposed to the full RGBA gamut!)