There is no "IPv8". Any crackpot can submit an internet-draft to the IETF, and this person happened to call theirs IPv8. If the submitter actually read the draft rather than feeding it to the slop cannon, they would have realized it is also a LLM hallucination that someone uploaded to IETF.
It's not JPEG like at all, unlike JPEG it is using the DCT only for the loss function, so it can have frequency weights, having the same approximate effect as JPEG's quantization matrices (at least, according to the slopped-out description). Whether that actually improves things for this type of content is unclear.
Yes. The default ffmpeg build enables everything, and most distros follow suit. Security conscious web services generally disable a lot of them, but there is no official list on which are considered more secure than others, so every site tends to have its own unique mix.
Which is completely wrong by the way, JPEG-XL quantizes its coefficients after the DCT transform like every other lossy codec. Most codecs have at least some amount of range expansion in their DCT as well, so the values quantized might be greater bit depth than the input data.
I do not understand the connection between the patent concerns in the article and open-source 3D printing. In particular, the patent issues seem to be the case for all non-Chinese 3D printer companies, whether open source or not. I am not sure how sharing your designs makes this worse (I suppose with the original drawings it's a bit easier to write a patent in bad faith - but certainly not necessary). Something like a defensive patent grant might make a lot of sense (see Opus, AV1 etc) but that's also independent of whether the implementation is open source or not.
The AR coefficients described in the paper are what allow basic modeling of the scale of the noise.
> In this case, L = 0 corresponds to the case of modeling Gaussian noise whereas higher values of L may correspond to film grain with larger size of grains.
Almost none of the games pictured are actually "doujin" games - they are commercial publishers.
Also, the reason we don't remember PC-98 is because it was never sold in the US (except for the very unpopular APC-III). It was the most popular computer on Japan from late 80s to early 90s and is well remembered there. Being the most popular PC, there is a huge amount of software for it, including huge amounts of office and productivity software, many genres of games, and plenty of Western ports.
You don't need to store two whole independent images. The high quality image can predict from the low quality image, and the low quality image can be a lower resolution, too. It is less efficient than storing one image, but more efficient than storing two independent images.
Digital video tape formats (e.g. DV, HDV) are an example. Other containers that operate in this mode are TS and Ogg (and optionally, MKV). Any sort of live streaming format generally is, too.
Those were all SPI-alike, or at least run in their SPI mode, including the ones linked. (I also used a Nokia 6100 LCD back in the day, and it was SPI, though with a wider interface option).
This is not a "mirrorless camera sensor", at least how it's meant to be interpreted. While technically mirrorless like all webcams, the sensor is under a quarter of the area of the smallest Sony mirrorless intechangeable-lens cameras.
Interestingly, the smooth bokeh has become a bit popular and is available with Canon "defocus smoothing" lenses (among other older examples). Rather than varying the aperture size over time, these just have a ND filter with the aperture window function coated on (and also a normal iris - the effect works best at the largest aperture setting).
Cortex-M4/M33 are pretty widely deployed on microcontrollers with control hardware, for example the STM32G4 and Reneasas RA series.
There's still a few reasons not to use it, though. Saving and restoring the float registers adds interrupt handling overhead. If you can fit into 16 bit integers, you can also use the 2 way SIMD instructions and get at least double the throughput.
Finally, floats themselves have a lot of footguns. You have to be very careful about propagating NaNs etc into control loops. It's also really easy (in C) to accidentally promote to double.
The size of most electric motors is proportional to the torque they produce - so if you can spin it faster, you can get more power for the same weight. There are some other factors that make high speed worse - for example, bearing and core losses. The PCB motor is a coreless motor though, so it has no core loss, biasing it even harder towards high speed operation.
Propellers generally get less efficient with higher speeds though, which might be a bigger factor than any of this.
Except they compromised on the very issue of media formats. They are making an unnecessary fight between two royalty-free formats, yet compromised and are hosting videos in royalty-bearing formats in their website. https://www.fsf.org/blogs/community/the-fsfs-approach-to-usi...
Waveform Lighting bulbs have a great CRI and no camera visible flicker, but even they are overdriven/undercooled. I've already had one fail because of the PFC chip (I did an autopsy). They also don't have enough bulk capacitance to not flicker when other nasty loads are on the line.
I did find these tables from Budget Light Forums handy for shopping, however the fact that you have to use these I think only reinforces the point of the article:
A progressive image format doesn't really fully solve the problem, it's only a potential bandwidth improvement. In both the case of a progressive and non-progressive image, you potentially prefetch the wrong asset - either a too low resolution image, or too few bytes of the progressive image, and you are stuck either waiting or displaying a too low resolution version of the image. The only advantage of the progressive format is that the prefetch bytes aren't wasted - as a rough estimate, if you grabbed the 1x image instead of 2x, you ended up using 125% as much bandwidth as intended. A nice improvement but also much smaller than just using a better image format in general. Likewise, it doesn't remove the need for container queries, you'd still at least want a byte offset for the complete base layer.
>The subset of AV1 supported by hardware is much narrower than what is in practice used in AVIF images
The majority of AVIF images are hardware decodeable, even if most viewers don't bother with it. The biggest limitation is that profile 0 decoders are 4:2:0 only, but that describes the majority of Web images.