Hacker News new | past | comments | ask | show | jobs | submit login
Better Portable Graphics (wikipedia.org)
186 points by tosh 10 days ago | hide | past | web | favorite | 123 comments





Image compression is complicated. Licencing topics, decompression cpu time, decompression memory use, decompression memory bandwidth use, compression time, is asymmetric slower but more efficient compression available, multi-threading, how much of the decoding can be shadowed during the data transfer, how many levels of progression are preferred, global image artefacts (such as banding) that don't appear in objective metrics, inter-frame copying ending up copying strange stuff around, red colors tend to not to be compressed with great success (there is no gamma compression for red in the eye, but in image formats there is), how much the image format is for the eyes and how much for the metrics, are the results the same on different platforms/implementations, is alpha supported, how good is the HDR modeling and its rather non-linear relations to gamma and colors in general, does the image format tend to preserve the quality of materials such as wood, marble, skin, cloth -- or replace them with cheap plastic imitation, some image formats work dramatically well at low BPP (<0.5) but start failing when compared to old JPEG at higher BPP (2.5+ BPP). Some image formats decode only a few megapixels per second which can be a disaster if your images happen to be in the 40 megapixel category.

Overall, it is a very complex landscape.


Any info on the future for PIK, is it on track to be assimilated into JPEG XL or will it remain a separate project ?

> there is no gamma compression for red in the eye

What does this mean? Do you have a citation to a source explaining whatever this is trying to say using precise standard color science terminology?


Please don't cross-examine people like this on HN. Threads here should be thoughtful conversations, not boxing matches.

https://news.ycombinator.com/newsguidelines.html


I am not “cross-examining” anyone.

I am curious what this referred to, because I have never heard such a thing, and it doesn’t match my understanding of human color vision, a subject which I have studied fairly extensively. It was stated authoritatively, without any elaboration or evidence.

I am asking for a citation so I can understand in more careful technical terms what claim is being made.

(P.S. Having site moderators step in to discourage basic good-faith questions is a bad show.)


Well, moderation is guesswork and sometimes we guess wrong. Since you say your intent was to simply ask, I believe you. But it didn't read that way to me, which means it probably didn't to some others too.

FWIW, the part that tipped me into thinking you were being aggressive was "whatever this is trying to say". That is the kind of thing people put into questions as a snarky swipe about someone being incoherent. Also, "do you have a citation to a source using precise standard science terminology" has a tinge of the same thing, since asking so bluntly and immediately for a citation is a way of not asking the commenter to explain what they meant themselves. Again, this is the sort of thing people do in internet comments when they're being haughty and dismissing the other person as ignorant. Especially a certain kind of technical haughtiness gets expressed this way.

There's nothing wrong with asking for a citation, of course, but since it has become a sort of putdown trope, one's question should include enough information to convey intent. And in normal conversation one would typically ask the other person to explain what they were saying first.


How would you express the sentiment:

“This statement seems incoherent based on what I know about the subject. To be charitable, this implies that it means something different than my interpretation, but was rendered confusing when simplified or expressed using terms pitched at laypeople. Could you please explain it using expert-targeted terminology or provide a citation to someone who does, so I can evaluate the claim on its merits instead of dismissing it as nonsense?”

In a concise but friendly/productive way?


I might say "I don't understand what this means. Can you make it more precise?". Or even just "What does this mean?", which you started with.

I'm sorry that I misinterpreted you. We're always matching comments against the most common patterns, and there are definitely comments that only appear to be matches and in reality weren't meant that way. There was another case of this yesterday: https://news.ycombinator.com/item?id=20415246.


Here's my take:

> "there is no gamma compression for red in the eye"

I'm not familiar with this terminology, at least in this context. Would you mind expanding on this? If you've any references I might use, that would be helpful, too.


I'm pretty sure that's not literally true. For example, take a CRT, with its built in power law voltage-to-intensity response (the original gamma correction). If the eye didn't compress red, you'd see large shifts in the color of a white color ramp.

Don't you know every HN thread needs its standard armchair top comment rebuttal on how TFA is actually wrong and the author is naive and doesn't really understand the problem with all its intricacies?

The top comment rebuttal is written by the author of the WebP lossless, https://github.com/google/butteraugli and https://github.com/google/pik so calling it armchairing doesn't really seem appropriate.

Ouch


I know you are being a little tongue-in-cheek here, but I remember there was an Alvy-Ray Smith paper submitted about sampling scenes in time-and-space (and then filtering semi-super-sampled inputs), and it wasn't just the top comment. EVERYBODY knew better than ARS. Without having any DSP background. It was both amusing and sad.

Please see AVIF (https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVI...) for an open, royalty-free alternative with similar or better performance.

And if you must use HEVC-based imaging, consider HEIF which has considerable support.


Last week, I encoded a bunch of images into AVIF. For the same dimensions and roughly same file size, AVIF images are dramatically clearer than JPEG. I wish I could start using them right now, but:

1. The AVIF encoder I was using[0] is based off libaom, which means a 1080p image takes almost 30 seconds to encode. rav1e is supposedly much faster, so I wonder how well it would do for AVIF.

2. Almost no viewer or browser support, and what does is usually some kind of beta or preview. (VLC nightly, Windows 10 AV1 plugin[1])

[0] https://github.com/Kagami/go-avif

[1] https://www.microsoft.com/en-us/p/av1-video-extension-beta/9...


> Almost no viewer or browser support

For browser support it should be possible to implement a poly-fill similar to https://github.com/UprootLabs/poly-flif which renders images in the FLIF format (https://flif.info/) into canvas elements.

FLIF as a format might be worth looking at while you are reviewing the area.


There is an AVIF polyfill, but it has lots of important edge cases.

https://github.com/Kagami/avif.js

I'd rather keep it simple and not deal with more JS, and I'm OK with using JPEG for now. (I've been using mozJPEG for years)


> which means a 1080p image takes almost 30 seconds to encode.

As you mention, rav1e would help, but HEVC/HEIF is only acceptable in speed due to hardware support.

AV1 is slowly making its way into silicon, though. I'm personally interested in seeing this make its way into cameras - even when I shoot in RAW, I often just use the off-camera JPG. I'd love for that to be AVIF instead.


HEIC/AVIF container is a complicated kitchen sink. It's closer to being a PowerPoint file than an image format. It's an unnecessarily large attack surface and a ton of features that nobody will (correctly) use anyway. The reference implementation is a ton of C++ code I would not dare to use in a security-sensitive application. OTOH libpng is a single C file, and it just wraps a single HEVC payload.

For that reason I'd say that if you can license HEVC, use BPG, not HEIF. And I'd love to have an AV1-based BPG version.


> HEIC/AVIF container is a complicated kitchen sink. It's closer to being a PowerPoint file than an image format.

This is untrue. While anything written by a working group that isn't trying to get to the moon with a below-average calculator will be more complicated than necessary, it is not a kitchen sink.

Both AVIF and HEIF store just a sequence of images with metadata (EXIF, depth maps, animation frame timings, profiles, ...). It's comprehensive, sure, but not a kitchen sink.

The AVIF spec is quite readable: https://aomediacodec.github.io/av1-avif/

> The reference implementation is a ton of C++ code I would not dare to use in a security-sensitive application.

You shouldn't be concerned because the implementation is big—you should be concerned because it is of non-zero length and parsing wild data. You need a safe port regardless if you're going to play the security sensitive card. BGP being C is an equal liability.

I don't want neither BGP nor HEIF to become popular at the cost of AVIF due to being based on HEVC, but I see no significant differentiation between them—HEIF is already established and does the trick.


small typo: libbpg, not libpng

Thanks, very small but led me to jump to complete misunderstandings about bpg, png, and libpng

The underlying HEIF container is unfortunately super complex, but the AVIF specification is based on the subset known as MIAF, which makes it a lot saner to implement.

I actually just discovered AVIF from the related links in this submission. Firefox planning to support it sounds promising.

I wish they won't use .avif file extension. It becomes .avi on old systems with 3 letter extensions! AV1 already looks like AVI. avif will be even more confusing.

Which currently supported OS limits extensions to three letters this day? Only EOL'ed Windows versions come to mind, but these are not relevant for a new file format.

You can see how unbelievably better this is than JPG (at almost any file size) here:

http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&j...

Or here:

https://bellard.org/bpg/lena.html

The difference between webp from the first link is actually quite small (http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&w...).

Additionally you can find the Javascript decoder here:

https://github.com/xingmarc/bpg-decoder

It's 215k of Javascript though so isn't really that practical in most cases and I'd worry about how it was affecting battery life. It'd be very interesting to do some tests and see.


> unbelievably better

I don't know that this qualifies as unbelievable. This is just good marketing and spin. The image in that link is exploiting the fact that modern codecs specify upsampling filters, so the HEVC half looks smoothly varying while JPEG can, per spec, only look pixelated when blown up like that.

There's absolutely no reason that thing couldn't have shown you a jpeg image rendered with bilinear filtering, which of course is what you'll see if you put that JPEG on a texture and scale it up using the GPU.

But it didn't, because it wanted to convince you how much "unbelievably" better HEVC is. Meh.

I mean, to be clear: HEVC is absolutely better, to the tune of almost a factor of two in byte size for the same subjective quality. Just not like this. If you've got a site where still images are a significant fraction of your bandwidth budget (and your bandwidth budget is a significant fraction of your budget budget) then this could help you. In practice... static content bandwidth is mostly a solved problem and no one cares, which is why we aren't using BPG.


> There’s absolutely no reason that thing couldn’t have shown you a jpeg image rendered with bilinear filtering, which of course is what you’ll see if you put that JPEG on a texture and scale it up using the GPU.

That’s not true, this particular JPEG will not look smooth on a GPU. The visible blocks are 8x8 pixels, not 1 pixel. The blocks would still be blocky because the compression has reduced them to only the DC component. This means the JPEG decode would still decode large blocks into texture memory and the GPU would still render large blocks with a slight blur between the 1 pixel borders of the 8 pixel blocks.

> In practice... static content bandwidth is a mostly solved problem and no one cares, which is why we aren’t using BPG.

I don’t believe that’s true either. I don’t know what you mean about bandwidth being “solved”, but more data is more data. If everyone could reduce their static images today by 2x without thinking, I’m pretty sure they would. I would on my sites if I could. The reason that BPG (or any other format!) isn’t yet being used is lack of browser support and tools and licensing and consensus, not because nobody cares about bandwidth. If what you said is true, then JPEG & PNG would never be replaced, but it’s already starting to happen.


The point was that, to first approximation, the internet is YouTube and Netflix. Static images are noise.

And I'm sorry, but if that JPEG is showing artifacts like that it was simply miscompressed, likely deliberately. I repeat, there is absolutely no reason an image of there same byte count cannot look just fine on that screen. For goodness sake, just reduce the resolution if nothing else.


The JPEG was compressed to death deliberately, yes. That's the point of the comparison; for the same (tiny) data size BPG gives you a clearly better result. BPG is workable in situations where JPEG isn't.

> For goodness sake, just reduce the resolution if nothing else.

Reducing the resolution would not work and is not the same thing. You would still get 8x8 DC blocks in a smaller JPEG at the same compression rate, and higher detail in the BPG. The BPG is provably better than the JPEG, and since you already know that and talked about it above, I'm a little confused by your argument.


I think there often is a point when reducing the bitrate further while keeping the same resolution is a worse choice than dropping the resolution. I believe one of the tricks of AV1 is to internalise this trade-off.

More generally, doing visual comparisons of codecs is full of traps. Since quality often falls off rapidly at a certain point it's possible to show your codec off by choosing the exact point to compare to maximise the difference. This is almost certainly the case if you're comparing against jpeg and it's starting to totally fall apart.

It's not that it doesn't correctly show that one is worse than the other but it's probably not a good visual reflection of the true scale of the difference any more than ramping up the bitrate until everyone would think they are indistinguishable.


Sure, yes, but the comparison in question isn't the only comparison, it's just one of many. Letting people see the difference visually for themselves is more tangible and less questionable that putting up two file size numbers and claiming they're equal quality. And if you think about it, it similarly wouldn't completely be fair to BPG to turn up the quality so that the JPEG looked reasonably good, because the BPG file would be in the range of diminishing returns per byte.

It is fair to point out that JPEG falls apart below a certain compression threshold while BPG doesn't, even if it's a little bit apples to oranges. I prefer the way @enriquito said it https://news.ycombinator.com/item?id=20419900 but I disagree with the hyperbolic claims in this thread that this comparison is outrageous or complete spin or cheating. It's a data point that has some actual merit, and BTW happens to agree with the other data points we have.


That picture at those dimensions and at that file size will show those artifacts. That's what the demonstration page is trying to show.

But that's completely artificial (and in the circumstances, outrageously spun!), because no one sane would compress a JPEG to a level where the macroblocks become flat blocks. You compress it at a resolution that captures the relevant detail, then display it with a filter that upsamples linearly. Nowhere on the internet is there an image that actually looks like this, because the "problem" being "solved" here doesn't exist in practice.

I mean, it's true that IF you do that, that h.265 will save you by having control over filtering. But that's not a fair comparison, at all.


I think you are missing the point of the comparison. Nobody says that JPEG images like this are common.

The point is rather that you could make a passable image of this bitrate using the better codec. It opens up a new level of compression not possible with JPEG.

If you downsampled the JPEG enough to get the same bitrate without blocking artifacts, it would look like a blurry smear, which is better than a bunch of 8x8 flat blocks but not that much better.

Maybe it would be worth including an additional JPEG downsampled-compressed-decompressed-upsampled view. You’d be able to see that jumping through those hoops doesn’t really give satisfactory results.


> The point is rather that you could make a passable image of this bitrate using the better codec. It opens up a new level of compression not possible with JPEG.

This is simply not correct. Anyone can get a passable image with that bit size. You're trying to stipulate "image pixel size" as some kind of inviolate thing, when it's not in reality. In reality, web content authors don't do insane things with their compression settings (I mean seriously: how would you even produce this? Standard conversion tools, for obvious reasons, will never emit an image like this). This isn't a real argument. This is cheating.

> it would look like a blurry smear,

Assuming facts not in evidence. The image in h.265 is plenty smeary already, FWIW. I think we both know that if this were true, the spin in the link would have done that instead of cheating with macroblock resolution. But in fact the blurry smear looks just fine, so they had to cheat.


Here’s what this image looks like if I rescale the original to half this size, save it using Adobe Photoshop’s JPEG encoder at ~26 kb size, then enlarge it back to double size:

https://i.imgur.com/t8GWPxX.jpg

It looks like garbage. It would still look like garbage if you resized it to some different size and used the appropriate level of JPEG compression to get a 26 kb image. JPEG just isn’t good enough to make this image workable for 1300x900 pixel output using only 26 kb.


> It looks like garbage

Sigh. Not like the garbage in the link above it doesn't. If this was the image in the link we all would have nodded and said "yup, looks about worth a doubling of byte count" and we'd all be in agreement.

Instead, the absurdist misencoded nonsense above gets thrown around as proof that BPG is some kind of revolutionary technology, and a bunch of us have to step in to debunk the silliness.

It's twice as efficient (roughly). Just say that and leave the spin.


What spin? You're the one getting confused about the point of the demo - to show that for very low byte count you can get a reasonably clean BPG image (when compared to JPG it's much much much better or can't you see?); so that people can be more informed about it's relative size/performance ratio at one data point.

I find it amazing that you seem to be adding in all sorts of nonsense about scaling images and filtering and such. It's not relevant to the discussion about at X filesize and res JPEG looks appalling and BPG looks pretty passable.

This is the widest distance between the two formats for sure, but if you want large hires images at very small file sizes BPG is a pretty nice format. As I go on to say the savings are outweighed by the cost of including the decoder plugin and the probably battery and memory cost this incurs.


> I don't know that this qualifies as unbelievable. This is just good marketing and spin. The image in that link is exploiting the fact that modern codecs specify upsampling filters, so the HEVC half looks smoothly varying while JPEG can, per spec, only look pixelated when blown up like that.

I think you're focusing on the background? I agree that they should have masked the background out, but if you look instead at the first yellow segment of the rear wing near the body, there is clearly more available detail in the HEVC side.


A few times I have looked at the possibility of switching from JPEG to another format for photo web sites and every time I have I've come to the conclusion that you can't really win.

There are three benefits that one could get from reducing the file size:

1. Reduced storage cost

2. Reduced bandwidth cost

3. Better user experience

In my models, storage cost matters a lot. You can't come out ahead here, however, if you still have to keep JPEG copies of all the images.

Benefits in terms of 2 are real.

Benefits in terms of 3 are hard to realize. Part of it is that adding any more parts to the system will cause problems for somebody somewhere. For instance, you can decompress a new image format with a Javascript polyfill, but is download+decompress really going to be faster for all users?

Another problem is that much of the source material is already overcompressed JPEG so simply recompressing it with another format doesn't lead to a really improved experience. When I've done my own trials, and when I've looked closely at other people's trials, I don't see a revolutionary improvement.

A scenario that I am interested in now is making desktop backgrounds from (often overcompressed) photos I find on the web. In these cases, JPEG artifacts look like hell when images are blown up, particularly when images have the sharp-cornered bokeh that you get when people take pictures with the kit lens. In that case I can accept a slow and expensive process to blow the image up and make a PNG, something like

https://www.mathworks.com/help/images/jpeg-image-deblocking-...

or

https://github.com/nagadomi/waifu2x

The other approach I imagine is some kind of maximum entropy approach that minimizes the blocking artifacts.


Fine detail is still better preserved where JPEG blows it away on low Q settings. A filter can't reconstruct that information.

Probably, but that effect is subtle and not the "OMG THIS IS PIXELATED" nonsense the linked page is showing.

I'm not saying BPG isn't better, I'm saying that link is ridiculous and doesn't capture the much more modest gains that it actually offers.


Maybe using https://github.com/google/knusperli as the JPEG decoder would give a fairer comparison?

How come all of google's size-related software ends in 'li'? Zopfli, brotli, knusperli...

It’s the Swiss German suffix for forming diminutives (as “booklet” is to “book” in English): https://en.wiktionary.org/wiki/-li#Alemannic_German

And that’s because those codecs are developed at Google Zürich. Knusperli, Brotli, Brunsli… those are all pastries (Brot means “bread” in German).


They are developed in switzerland

This comparison is a bit unfair to JPG. There are many JPG decompression algorithms. The "simplest" one consists in reconstructing the image from the given quantized DCT coefficients. But this is not the only one. Modern decompression methods (such as the one implemented by BPG) find the cleanest possible image that would get compressed to the given JPG file. These decompression algorithms eliminate most blocking artifacts on uniform regions, and that would be a fairer comparison.

Nonetheless, the BPG format is a super-incredible hack.


That would make a lot of sense for JPEG, I wonder why such deblocking decoders aren't widespread.

I've been planning to write an adversarial neural network based JPEG decoder that would find the most realistic possible image that would get compressed to the given JPEG... I would love to have such a decoder integrated into browsers!


> I wonder why such deblocking decoders aren't widespread.

There are many, but mostly focused on output quality, and slow, and written in matlab using fancy tools.

If somebody submits a simple patch (written in pure C without dependences) to the jpeg reference distribution, and the code is very fast and good enough, it will most surely become mainstream. The thing is, that the people who know enough math to create a good jpeg decompressor do not tend to be well-versed nor interested in C programming.


I haven't worked with matlab—nor is my math up to that kind of snuff by a long shot— but how hard would it be for an experienced programmer to port it over effectively?

> how hard would it be for an experienced programmer to port it over effectively?

They should at least grasp a bit of the math involved, which is possible but not elementary. A full re-implementation would not be hard, the hard thing would be to remove the non-essential steps that increase the quality by a negligible amount but have a huge impact in the running time. Knowing what parts of the algorithm are essential and what parts are superfluous is not easy if you don't understand the algorithm.


> remove the non-essential steps that increase the quality by a negligible amount but have a huge impact in the running time. Knowing what parts of the algorithm are essential and what parts are superfluous is not easy if you don't understand the algorithm

Yeah that's what figured but hoped against. I still might have a curious look later...

any pointers for where a good resource might be?


A canonical starting point is the Bredies-Holler work on TGV-based decompression (a significant improvement over the TV model, that cannot correctly address block artifacts).

Look at the two-part article from 2015 here:

https://imsc.uni-graz.at/bredies/publications_de.html


Decompression speed is extremely important. How fast would such a implementation be?

It would be multipass, so it would render ever increasing quality reconstructions, limited by a configurable limit, so that you can limit power consumption on mobile devices.

Sounds like the exercise would be more for the sake of it rather than trying to develop some widespread new decompression method.

This is a great idea. Please post to Show HN when you ship something.

I believe a better such algorithm would also help progressive jpegs load in better and so give JPEG a pretty strong practical advantage over formats that don't support that. And it's even better if http2 loads all the images smartly rather than one at a time.

https://blog.cloudflare.com/parallel-streaming-of-progressiv...


If I was making a graphics format I'd have one bit in the header for: is_lena. Then I could have very small Lena images /joke

Original Lena or the remastered scan?

Codecs with built-in blurring always totally crush in "Tiny" demos. However, these are only good for demos where viewers care about not seeing artifacts, rather than appreciating the content.

For realistic scenarios, you can't use compression that makes faces look airbrushed, makes wood and hair look like a plastic imitation, etc. If your designers/marketers/photographers care about "grain" in photos, they'll hate you for applying benchmark-winning aggressive smoothing and deringing.

Note that when you switch the benchmark file size to "Medium", the difference is not that big. On "Large" all codecs, except some pathological cases, are nearly identical.

And that makes JPEG stay, despite all newer codecs being "unbelievably" better. Everything newer than JPEG can smooth out blocking artifacts, but quality levels useful for still images don't exhibit blocking in the first place.


Just a reminder all these comparison were made with very old version of x265. And while x265 as an encoder is quite good, it certainly isn't as mature as x264. There are certainly much better commercial HEVC encoder out there.

> There are certainly much better commercial HEVC encoder out there.

The x265 team has repeatedly attempted to refute this claim, but it’s a lot of throwing numbers and lots of mud back and forth between the different implementors. Do you have anything solid to back that statement?


Beamr 5 would be one. [1] But my x265 experience is with pre 2.8. Not sure how much improvement there is in 3.0 and 3.1.

My point is not that x265 isn't "good" in absolute terms, it just isn't x264 level insanely good. In AVC era, x264 was absolutely amazing in the details. And just to point out, comparing encoder is hard and depends a lot on materials and target bitrate.

[1] https://www.streamingmedia.com/Articles/Post/Blog/HEVC-IP-Ow...


Yeah, that’s actually the one I was referring to. The rebuttal to it left me unsure: http://x265.org/beamr-hevc-encoder-comparison/ (it is also from a while ago, before 3.x I believe)

In that link bpg tiny is insanely better at under 25kB than jpeg medium at 42kB. Looks really like this would be great for all the very small pictures and icons on the web.

That US air force base chapel is in Horizon Zero Dawn!

Presuming this was posted by someone exploring the works of Fabrice Bellard after reading the HN comments here https://news.ycombinator.com/item?id=20411154

This is amusing to me, because I knew about FFMpeg and QEMU and jslinux, and yesterday found out about quickjs, and so I like how the "small" project is just a complete and better replacement for jpeg. The guy is not human.

This pattern continues to amuse me. I wish for some analysis of these connectivity graphs, but I guess it's near-impossible to do accurately without capturing the poster's history and looking at how they stumbled from previous HN posts/comments onto the thing they post now.

It also crosses site boundaries. https://news.ycombinator.com/item?id=20366844

Which is why I think user's browser history would be needed. And that's not possible to do at statistically significant/useful scale.

I think you could achieve a first-order approximation by crawling front-page links a couple levels deep and seeing what's connected.

The guy who wrote BPG is a legend. I was looking at his home page where it lists cool projects - https://bellard.org/ and I was thinking this is a great list of really popular projects. Then I realized he made all of them! People that make this many important contributions should be better recognized.

QuickJS is a great little JS engine as well that he wrote and is super easy to embed :)

And once again software patents are the hair in the soup.

Agreed. An AV1 based format would be more interesting, and likely have better compression ratios.


Anytime I see anything with Fabrice' name on it I'm immediately intrigued. He's just on a different level. His list of projects is simply astounding. I can duly recommend checking out some his other projects at https://bellard.org.

sans patent issues:

https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVI...

still waiting on the software support.


iOS is already using HEIF, which is basically the same thing in a different container format. That seems a much more likely candidate for actually being taken up.

Correction: In addition to macOS and iOS, Windows 10 and Android apparently also support it already.

You can edit your original comment rather than reply to yourself ;-)

Fabrice strikes again! FFMPEG, QEMU, TCC . . . .

https://bellard.org/


How this guy finds the time to work on these very different projects? Some of them require skills that are very specific, how can you pass from writing QEMU to TCC to the 4G station ... What does he do for living, how does he spend his free time?

Writing emulators, compilers, operating-systems, and codecs are all standard-skills of any low-level systems programmer. My entire team of 50+ people are capable of doing this stuff. The difference between us & Fabrice are: (1) we work for a major company & none of our stuff is publicly available; and, (2) he's still at least head-and-shoulders above most of the people doing this. He'd easily be in the top 5 for my team, and certainly better than of the kids under 40.

Dude is a goddamn genius.

He's a god amongst men.

patent encumbered. non-starter.

And worse than what the wikipedia article states (Bellard asserts that devices licensed for HEVC would be able to use BGP since it's the same technology), licenses are usually given for a certain purpose. I'd be wary about reusing licenses for unrelated tasks like that.

I agree. We already have JPEG, a format that can be used without obvious patent problems. I don't think the world needs a format with obvious patent problems.

Saving some bytes is nice, but when people are streaming videos and audio, shaving off a few bytes isn't worth the endless lawsuits.


Seems like the same strategy starting with AV1 would be a good solution.


Thanks. I went to the AV1 page but didn't notice that section. Seems promising, with implementations already cropping up.

I'm looking forward to FUIF - Free Universal Image Format https://cloudinary.com/blog/introducing_fuif_responsive_imag... Created by the same person who created FLIF (already an amazing format)!

Better yet, it's probably the most-likely technology to be accepted into the upcoming JPEG XL standard!


The problem with FUIF is probably that it's not all that efficient at encoding images, which is probably why there are zero comparisons or demonstrations of the actual images that can be found easily by going to the repository or the authors' blog. The one FUIF image I've seen was the one in their clip showing generational loss with various codecs.

FUIF has the ability to losslessly transcode from JPEG. This will make it very useful in a couple of important use cases. But by constraining itself to DCT in this way, I assume it performs relatively poorly compared to other modern alternatives when compressing from a RAW source.

You can already use native av1 to display images in browser. You simply encode your image to a single frame av1 webm with ffmpeg. Browsers will automatically display the first image fully rendered, because it acts as a thumbnail. Afaik no need for autoplay privledges.

Is there a reason that browsers don't jump on the bandwagon and implement codecs for all reasonably-stable image codecs (save this one, which seems to be patent encumbered)?

i.e.: why doesn't Chrome support AVIF? Is it because it competes with their own invented-here WebP?

It seems like adding new image codecs for given content types would be pretty trivial if the libraries are available and stable and license compatible; why be conservative and not just support the newish ones to help the best ones gain traction?

It seems like browser vendors are just dragging their feet.


Because browsers have an enormous API/file support surface as is, and each new image format can be a significant amount of code to support essentially forever.

Webp now is supported by pretty much every browser, but a lot of image viewers don't support the format yet. There has to be a certain amount of momentum to justify supporting a new image format.


Security liabilities, most likely. Buggy decoder libraries widen the surface for exploits. And no software is bug free, nor first party vetting is free, nor sandboxes can be blindly trusted to do their job. Better not to take any unnecessary risk, especially since browsers are already complicated enough.

1. Security

2. Bloat

3. You can't really stop supporting media formats. Once you put anything into a browser, you can't take it out. The best that can be done is depreciate it forever.


There is also FLIF (https://en.wikipedia.org/wiki/Free_Lossless_Image_Format) which has a nice property: it is adaptive by design, that is, you can only look at the first X bytes and get a first approximation of the image, and the further you go, the better it becomes. It also allows for both lossless and lossy compression.

I wonder how they compare.

(Don't take my word for that, I'm no expert on the subject)


JPEG does that too, you can enable progressive rendering in the encoder. Having it enabled does not make the image larger in my experience.

Somewhat OT but are there any JS libraries (or maybe servers via query params) that you can configure to only download X-bytes from progressive images? For example if you detect your user is on a slow mobile connection you could download at most 50kb from all the images on your site in order to keep it fast.

I knew I recognized that name, it's one of the main ffmpeg and QEMU developers! If BPG is up to the same quality than those two, then it has to be a great format!

Apple has unilaterally pushing their HEIF format to replace JPEG after iOS 11 - to combat the criticism of they differentiating their iPhone/iPad by storage sizes and artificially make the base model a very small capacity (16GB for the longest time) and their storage not customer replaceable.

https://support.apple.com/en-us/HT207022


"Patent issues may prevent JPEG replacement by BPG despite BPG's better technical performance.[6]"

BPG meet GIF, GIF meet BPG. The most annoying thing about GIF in the early days were the damn Compuserve patents that they would go out of their way to hassle you with if they thought they could.


What about encoding/decoding performance?

> Current research works on designing and developing more energy-efficient BPG hardware which can then be integrated in portable devices such as digital cameras.

I guess it doesn't really matter that much, but I'm still curious.


Does something similar exist with AV1?


That's it? we're milking Bellard's treasure cave for upvotes now?

I'm sure there are people who haven't been on HN for ten years who haven't seen it. There's no Hacker Canon to discuss this stuff so people repost it here.

You probably know which comic this is without clicking on it

https://xkcd.com/1053/


Fabrice Bellard is a monster. I want to be just like him when I grow up. With a monstrous list of accomplishments.

Why bother when we have PNG?

Totally different algorithm for different purposes. PNG is lossless encoding, doesn't work well for photographs or complex images.

PNG works really fine for no HDR photos if you not are worry about the size.

And BMP, TIFF, DPX, EXR etc all work really fine if you are not worried about the size.

But being worried about the size is the whole point of image compression.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: