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.
Readit NewsTD-Linux commented on Open hardware desktop 3D printing is dead? josefprusa.com/articles/o... · Posted by u/rcarmo
TD-Linux commented on AV1@Scale: Film Grain Synthesis, The Awakening netflixtechblog.com/av1-s... · Posted by u/CharlesW
Grain is independent frame-to-frame. It doesn't move with the objects in the scene (unless the video's already been encoded strangely). So long as the synthesized noise doesn't have an obvious temporal pattern, comparing stills should be fine.
Regarding aesthetics, I don't think AV1 synthesized grain takes into account the size of the grains in the source video, so chunky grain from an old film source, with its big silver halide crystals, will appear as fine grain in the synthesis, which looks wrong (this might be mitigated by a good film denoiser). It also doesn't model film's separate color components properly, but supposedly that doesn't matter because Netflix's video sources are often chroma subsampled to begin with: https://norkin.org/pdf/DCC_2018_AV1_film_grain.pdf
Disclaimer: I just read about this stuff casually so I could be wrong.
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.
TD-Linux commented on The world of Japan's PC-98 computer strangecomforts.com/the-s... · Posted by u/ecliptik
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.
> "Worse" in what sense?
Worse as in not compressing as well. As I said, at high fidelity or lossless. At lower quality levels, AVIF files are smaller and JXL files are bigger. At higher quality levels, JXL files are smaller and AVIF files are bigger. At lossless, AVIF is worse than PNG, while JXL is much better.
> Like implied I'm not an expert, I'm just wondering why AVIF can't have faster loading with a preview function like JPEG has.
JPEG is fast to load regardless of its progressive loading feature. So there are really two things at play, speed of decoding, and whether partially loaded files can give you a preview. The slow decoding of AVIF is inherent to the design of the format, but different encoding choices can lead to different decoding speed. IIRC, the lower the encoding quality, the faster the decoding can be. And as for progressive display, that simply wasn't considered when AV1 was designed. You can do something funny and store two AVIF frames, one low quality and maybe lower resolution, followed by the full image, but then you're storing two images just to get a preview.
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.
TD-Linux commented on Writing an MP4 Muxer for Fun and Profit obsproject.com/blog/obs-s... · Posted by u/skrrtww
So this is a “soft” sequential access limitation (we can tolerate some random writes to data as long as it is small enough and short enough). I wonder if there are formats that result in finished indexed multimedia file with “hard” sequential access, when nothing can be overwritten.
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.
TD-Linux commented on MKBHD, Fisker, and "the worst car ever reviewed" twitter.com/MorningBrew/s... · Posted by u/redbell
Other reviews also voiced the same complaints. Here's one from November of last year that mentions things like the obnoxious animations: https://electrek.co/2023/11/21/fisker-ocean-review-coming-so...
I think the input lag on the accelerator pedal is what kills it for me, though.
TD-Linux commented on Electric Car Owners Confront a Harsh Foe: Cold Weather nytimes.com/2024/01/17/bu... · Posted by u/monero-xmr
A simple solution would be to warm the battery to a reasonable temperature but I don't know if that's feasible for such a large battery. It's not as easy as keeping a phone in an inside pocket vs an outside one. The car should be built with heaters around the battery. The power must come from the charger at charge time (but maybe the battery self warms itself while charging,) then from the battery. What's more: power for the heaters or power to move the car? Probably the latter.
All electric cars already do this, either with resistive heaters directly on the batteries or with water heaters in the coolant loop.
TD-Linux commented on Displays We Love Hacking: SPI and I2C hackaday.com/2023/12/21/d... · Posted by u/rcarmo
This means that you will hardly ever see a color display with an I2C interface
Statements like this make me assume the author of this article may be very young, as in the early 2000s tons of mobile phones and media players had colour LCDs with I2C interfaces, including famous Nokia models such as the 6100. 128x128, 132x132, 176x128, and similar sizes with 4k and later 64k colours was very very common. Some devices could play video on them too.
Edit: there is a somewhat de-facto standard for these small graphic displays and their instruction sets, split between "Philips clones" and "Epson clones", much like the HD44780 did for character displays: https://web.archive.org/web/20150912171758/http://wiki.s1mp3...
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).
TD-Linux commented on Opal Tadpole – A webcam for laptops opalcamera.com/opal-tadpo... · Posted by u/jnthn
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.
TD-Linux commented on FFmpeg is getting multithreaded transcoding pipelines twitter.com/FFmpeg/status... · Posted by u/raybb
You are not using hardware acceleration on the decoding side, and removing video output here. I wonder what happens if we use both hardware acceleration on video decoding and encoding, i.e. something like this on NVIDIA card
ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $outputNo video is being transcoded in the parent's command (-vn).