Could be done, but nothing is EVER simple regarding IPv6. :) What about EUI-64? Any special cases regarding TEREDO, ORCHID2, 6to4 addressing scheme (NOT the same as NAT64!), etc...?
Nevertheless, something like this could be an option.
The NTSC color coefficients are the grandfather of all luminance coefficients.
It is necessary that it was precisely defined because of the requirements of backwards-compatible color transmission (YIQ is the common abbreviation for the NTSC color space, I being ~reddish and Q being ~blueish), basically they treated B&W (technically monochrome) pictures like how B&W film and videotubes treated them: great in green, average in red, and poorly in blue.
A bit unrelated: pre-color transition, the makeups used are actually slightly greenish too (which appears nicely in monochrome).
I was actually researching why PAL YUV has the same(-ish) coefficients, while forgetting that PAL is essentially a refinement of the NTSC color standard (PAL stands for phase-alternating line, which solves much of NTSC's color drift issues early in its life).
It is the choice of the 3 primary colors and of the white point which determines the coefficients.
PAL and SECAM use different color primaries than the original NTSC, and a different white, which lead to different coefficients.
However, the original color primaries and white used by NTSC had become obsolete very quickly so they no longer corresponded with what the TV sets could actually reproduce.
Eventually even for NTSC a set of primary colors was used that was close to that of PAL/SECAM, which was much later standardized by SMPTE in 1987. The NTSC broadcast signal continued to use the original formula, for backwards compatibility, but the equipment processed the colors according to the updated primaries.
In 1990, Rec. 709 has standardized a set of primaries intermediate between those of PAL/SECAM and of SMPTE, which was later also adopted by sRGB.
Worse, "NTSC" is not a single standard, Japan deviated it too much that the primaries are defined by their own ARIB (notably ~9000 K white point).
... okay, technically PAL and SECAM too, but only in audio (analogue Zweikanalton versus digital NICAM), bandwidth placement (channel plan and relative placement of audio and video signals, and, uhm, teletext) and, uhm, teletext standard (French Antiope versus Britain's Teletext and Fastext).
Honestly, the weird 16-239 (on 8-bit) color range and 60000/1001 fps limitations stem from the original NTSC standard, which considering both the Japanese NTSC adaptation and European standards do not have is rather frustating nowadays. Both the HDVS and HD-MAC standards define it in precise ways (exactly 60 fps for HDVS and 0-255 color range for HD-MAC*) but America being America...
* I know that HD-MAC is analog(ue), but it has an explicit digital step for transmission and it uses the whole 8 bits for the conversion!
> People don’t realize how many man hours went into those early decisions.
In my "trying to hunt down the earliest reference for the coefficients" I came across "Television standards and practice; selected papers from the Proceedings of the National television system committee and its panels" at https://archive.org/details/televisionstanda00natirich/mode/... which you may enjoy. The "problem" in trying to find the NTSC color values is that the collection of papers is from 1943... and color TV didn't become available until the 50s (there is some mention of color but I couldn't find it) - most of the questions of color are phrased with "should".
This is why I love graphics and game engines. It's this focal point of computer science, art, color theory, physics, practical implications for other systems around the globe, and humanities.
I kept a journal as a teenager when I started and later digitized it when I was in my 20s. The biggest impact was mostly SIGGRAPH papers that are now available online such as "Color Gamut Transform Pairs" (https://www.researchgate.net/publication/233784968_Color_Gam...).
I bought all the GPU Gems books, all the ShaderX books (shout out to Wolfgang Engel, his books helped me tremendously), and all the GPU pro books. Most of these are available online now but I had sagging bookshelves full of this stuff in my 20s.
Now in my late 40s, I live like an old japanese man with minimalism and very little clutter. All my readings are digital, iPad-consumable. All my work is online, cloud based or VDI or ssh away. I still enjoy learning but I feel like because I don't have a prestigious degree in the subject, it's better to let others teach it. I'm just glad I was able to build something with that knowledge and release it into the world.
Cool. I could have been clearer in my post; as I understand it actual NTSC circuitry used different coefficients for RGBx and RGBy values, and I didn't take time to look up the official standard. My specific pondering was based on an assumption that neither the ppm2pgm formula nor the parent's "NTSC" formula were exact equivalents to NTSC, and my "ADHD" thoughts wondered about the provenance of how each poster came to use their respective approximations. While I write this, I realize that my actual ponderings are less interesting than the responses generated because of them, so thanks everyone for your insightful responses.
Surprisingly by boatloads by Chinese manufacturers. Nothing really shady about it (standard concerns about raw materials excepted), but it is still used mainly for random embedded stuff where there is a need for a memory module but the design is from a time where DDR3 chips are not available. An ubiquitous example are those DVD players from random Chinese brands that are based on Mediatek's designs from 2004(-ish).
And this is rather an anemic take. The (proposed) UK VPN ban that was recently discussed here have a definition on what exactly is a "VPN" for the purposes of the ban (basically "VPNs generally advertised to normal consumers") but a lot simply shouted "ssh go brr" (and definitely did not read the proposed law). These "let's go techical" thinking never flies with the poeple who makes such legislation, and in (probably unpopular!) opinion we should talk to them in terms that they can understand. Yes, we don't want that law, but having a purist take would probably alienate regular people.
It doesn't really matter that a single person has found a loophole because many, many other people don't have such a luxury, and that's what the lawmakers are aiming for.
I have worked for fintech companies that mandate VPN use as a security measure.
It's going to be interesting when the majority of the UK accesses the internet via VPN because of the increasingly ridiculous hoops that the UK makes them go through, and the government tries to stop them while also allowing VPNs to be used by the tech sector.
I agree, these are two separate legal processes powered by the same technology. But the internet doesn't have any awareness of legality (thankfully) so we're stuck with only the technical meaning.
> The (proposed) UK VPN ban that was recently discussed here have a definition on what exactly is a "VPN" for the purposes of the ban (basically "VPNs generally advertised to normal consumers")
It’s not taking about IPsec tunnels between networkers, or a connection back to your home. It’s talking about surfshark
Maybe, at the moment, because when Surfshark is banned people will learn how to make their own VPN (like I said, it's not hard), or find some other source. And then the government will move to ban that, and we'll go round the loop again.
The point, again, is that the tech is the same, and there's no method for determining what purpose the VPN is being used for.
There is even a single company in the unique position to actually tell where exactly(-ish, considering CGNAT exists) where an IP address is located: Google. They do use the "enhanced location" data on Android devices to pinpoint where an IP is, so a single Android device can actually change fings for Google (and YouTube).
> on Windows you need to download support from the Microsoft store.
To be really fair, on Windows:
- H.264 is the only guaranteed (modern-ish) video codec (HEVC, VP9, AV1 is not built-in unless the device manufacturer bothered to do it)
- JPEG, GIF, and PNG are the only guaranteed (widely-used) image codecs (HEIF, AVIF, and JXL is also not built-in)
- MP3 and AAC are the only guaranteed (modern-ish) audio codecs (Opus is another module)
... and all of them are widely used when Windows 7 was released (before the modern codecs) so probably modules are now the modern Windows Method™ for codecs.
Note on pre-8 HEVC support: the codec (when not on VLC or other software bundling their own codecs) is often on that CyberLink Bluray player, not a built-in one.
reply