Posted by bentocorp 4 days ago
This one has a section on animation and cinemagraphs, saying that video formats like AV1 and HEVC are better suited, which makes sense. Here's my somewhat off-topic question: is there a video format that requires support for looping, like GIFs? GIF is a pretty shoddy format for video compared to a modern video codec, but if a GIF loops, you can expect it to loop seamlessly in any decent viewer.
With videos it seems you have to hope that the video player has an option to loop, and oftentimes there's a brief delay at the end of the video before playback resumes at the beginning. It would be nice if there were a video format that included seamless looping as part of the spec -- but as far as I can tell, there isn't one. Why not? Is it just assumed that anyone who wants looping video will configure their player to do it?
Remember when sites were allowed to play audio on a loop without permission?
Of course, not every video player supports them well. Which is kinda understandable, I can see how expecting 30 frames per second from a 30fps video would make things a lot simpler, and work right 99.9% of the time.
But we shouldn't be using animated GIFs in 2024.
The valid replacement for the animated GIF is an animated lossless compressed WebP. File sizes are are much more controlled and there is no generational loss when it propagates the internets as viral loop (if we all settled on it and did not recompress it in a lossy format).
<video playsinline muted loop> should be nearly as reliable as a GIF in that regard.
The one exception that I've found is that some devices will prevent videos from autoplaying if the user has their battery-saver on, leading to some frustrating bug reports.
As for your question about video looping: Nothing prevents that, although I don't know of a container format that has a flag to indicate that it should be looped. Players could eliminate the delay on looping by caching the first few frames.
HEVC does not have such a flag. Quite unfortunate
> Most browsers now recognize and support NAB, though it is not strictly part of the GIF89a specification.
So I guess the players for the new video codecs could do something similar and agree on some metadata to be used for the same purpose?
The “NAB” was introduced in Netscape Navigator 2.0, 50 million years ago.
The phrasing with “most browsers” and “now” is a bit weird, on part of whoever wrote that part of the Wikipedia article.
Every major browser that I know of has supported animated gifs since forever.
Any browser that doesn’t is probably either a non-graphical browser in the first place, or one that has like five people using it.
> Every major browser
There are only 2 major ones
And this brings us back to the main point - this is no "format" issue, Chrome could just as well support some metadata field as "loop for n" for the newer video files, and the situation would be the same as with NAB when Safari adds it.
- the 5% point you're responding to doesn't refer to the original "Every major browser"
- the original reponse just highlights that there is no non-pedantic difference between "most browsers" and "Every major browser", so that was the start of the anti-pedantism battle
There is a lossless ultra-packer for existing JPEG files. It's completely reversible, you can get byte-for-byte identical JPEGs back.
Then there is "VarDCT" mode, which acts like JPEG, lossy Webp, or video codecs.
Then there is "Modular Mode", a completely different kind of codec that has different kinds of compression artifacts than JPEG-like codecs. The compression artifacts you see tend to be more like sections becoming more pixelated, or slight color differences. Strong edges don't have ringing artifacts. Modular mode mainly is used for lossless compression, but also allows lossy compression.
[0] https://github.com/libjxl/libjxl/tree/main/lib/jpegli
[1] https://github.com/google/jpegli
[2] https://opensource.googleblog.com/2024/04/introducing-jpegli...
I guess Tiff is still the hot mess it always has been too... lol =3
edit: previous discussion about it https://news.ycombinator.com/item?id=41598170
I make photography/camera apps and would like to support JPEG XL natively (without having to rely on 3rd party code) so I hope it’s something they add soon!
Because Apple is all in in HEIC/HEIV. The "high efficiency" codecs that require up to a second on an M1 Pro to render an image. A comparable image in PNG renders instantly
· Original PNG image (2.6 MB)
· Name "high_fidelity.png", but in fact 298.840 bytes and format: JPEG
· JPEG XL (default settings, 53 KB): indistinguishable from the original
· Name "high_fidelity.png.jxl.png", but in fact 3.801.830 bytes and format: PNG
· WebP (53 KB): some mild but noticeable color banding along with blurry text
· Name "high_fidelity_webp.png", but in fact 289.605 bytes and format PNG
· JPEG (53 KB): strong color banding, halos around the text, small text hard to read
· Name "jpeg_high_fidelity.jpg", but in fact 52.911 bytes and format JPEG
The comparison does not make any sense,
everything is just wrong. Also when encoding the large original PNG image to AVIF, it has only 20.341 Bytes with no visual change, see: http://intercity-vpn.de/files/2024-10-27/upload/I guess that is because the noise from the lossy encoding creates more entropy, that then has to be losslessly encoded as PNG, which pushes the files size above the original?
means the original was
- loss-converted to JXL, measured as 53k
- then losslessly converted to PNG to be displayed on the website
And your AVIF is certainly not without visual changes. The colours are off and there is visible ringing.
> HEIC and AVIF can handle larger [than 35MP, 8MP respectively] images but not directly in a single code stream. You must decompose the image into a grid of independently encoded tiles, which could cause discontinuities at the grid boundaries. [demo image follows].
The newest Fujifilm X cameras have HEIC support but also added 40MP sensors--does this mean they are having to split their HEIC outputs into two encoding grids?
It seems like the iPhone avoided this, as 48MP output is only available as a "ProRAW" i.e. RAW+JPEG, which previously used regular JPEG and now JPEG-XL, but never HEIC.
Apple supporting it surely has to be a signal to begin wider adoption!?
If it becomes used in Firefox, maybe there's a chance that Google would see the benefit in picking it up?
[1] https://github.com/mozilla/standards-positions/pull/1064
>potentially introduce memory safety vulnerabilities across the myriad of applications that would eventually need to support it
Right, new code, new vulnerabilities.
You have to first read the image header, an optional ICC profile and finally a portion of the first frame. This first frame might actually be a preview generated by an encoder, but should be fine for our purpose and it's not hard to seek to subsequent frames anyway. The frame itself contains its own header and all offsets to per-frame sections ("TOC"), while there is always one LfGlobal section that contains the heavily downscaled---8x or more---image in the modular bitstream, even when the frame itself uses VarDCT.
Any higher resolution would require some support from the encoder. The prime mechanism relevant here is a version of the modified Haar transform named Squeeze, which generates two half-sized images from one source image. As each output image is placed to distinct sections, only one out of two output images is needed for low-fidelity decoding. If the encoder didn't do any transformation however (often the case in VarDCT images), then all sections would be required regardless of the target resolution.
Therefore it is technically possible and in fact libjxl does support partial decoding by rendering a partial bitstream, but anything more than that would be surprisingly complex. For example how many bytes are needed to ensure that we have at least 8x downscaled image? This generally needs TOC, and yet a pathological encoder can put the LfGlobal section to the very end of frame to mess with decoders (though no such encoder is known at the moment). Any transformation, not just Squeeze, has to be also accounted to ensure that all of them will produce the wanted resolution once combined. Since the ICC profile and TOC already require most entropy encoding stuffs except for meta-adaptive trees, even the calculation of the number of required bytes already needs about 1/2--1/3 of the full decoder in my estimate from building J40.
That said, I'm not very sure this complexity could've been radically reduced without inefficiency in the first place. In fact I've just described what I wanted when I started to build J40! I think there was an informal agreement that the ICC profile could have been made skippable, but you still need all the same stuff for decoding TOC anyway. Transformation is a vital part of compression and can't be easily removed or replaced. So any such tool would be definitely possible, but necessarily complicated, to build.