Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new PNG spec

programmax.net

Post reply on HN
Print view View original

571–580 of 622 posts

Re: A new PNG spec

#571

Post by kbolino »

mchusma wrote: post #373
bla3 wrote: post #342

Earlier quoted context omitted.

WebP lossless is close to state of the art and widely available. It's also not widely used. The takeaway seems to be that absolute best performance for lossless compression isn't that important, or at least it won't get you widely adopted.

I don't know that i have ever used jpg or png lossless in practical usage (e.g. I don't think 99.9% of mobile app or web usecases are for lossless). WebP lossy performance is just not worth it in practice, which is why WebP never took off IMO. Are there usecases for lossless other than archival?

I definitely noticed when the Play Store switched to lossy icons. I can still notice it to this day, though they did at least make it harder to notice (it was especially apparent on low-DPI displays). Fortunately, the apps once installed still seem to use lossless icons.

A lot of images should be lossless. Icons/pictograms/emoji, diagrams and line drawings (when rasterized), screenshots, etc. You can sometimes get away with large-resolution lossy for some of these if you scale it down, but that doesn't necessarily translate into a smaller file size than a lossless image at the intended resolution.

There's another problem with lossy images, which is re-encoding. Any app/site that lets you upload/share an image but also insists on re-encoding it can quickly turn it into pixelated mush.

Re: A new PNG spec

#572

Post by LinAGKar »

ProgramMax wrote: post #427

Author here. Hello everyone! Feel free to ask me anything. I'll go ahead and dispel some doubts I already see here: - It isn't really a "new format". It's an update to the existing format. - It is very backwards compatible. -- Old programs will load new PNGs to the best of their capability. A user will still know "that is a picture of a red apple". There also seems to be some confusion about how PNGs work internally.…

>we'll be researching compression updates for PNG Fifth Edition.

What sort of improvements might we expect? Is there a chance of it rivalling lossless WebP and JPEG XL?

Re: A new PNG spec

#573

Post by dylan604 »

account42 wrote: post #526
dylan604 wrote: post #318

Earlier quoted context omitted.

> You can losslessly re-compress a JPEG into a JPEG-XL file and gain space. Is that gained space enough to account for the fact you now have 2 files? Sure, you can delete the original jpg on the local system, but are you going to purge your entire set of backups?

Yes the whole point of lossless re-compression is that you do not need to keep the original JPEGs. Of course you don't need to "purge" backups, just let them rotate out normally. Also backup storage is usually cheaper than something that needs to have fast access speeds.

For people that shoot digital cameras saving as JPEG, it will a very cocky suggestion to tell them to toss out their camera original files!

You'll know JPEG-XL if real when camera manufactures allow for XL acquisition instead of legacy JPEG only.

Re: A new PNG spec

#574

Post by spauldo »

rhet0rica wrote: post #449
mikae1 wrote: post #345

Earlier quoted context omitted.

> There is just no need for a PNG update, just adopt JPEG XL. Tell that to Google. They gave up on XL in Chrome[1] and essentially killed its adoption. [1] https://issues.chromium.org/issues/40168998#comment85

From reading that, "gave up" seems to mean "deliberately killed it so their own WebP2 wouldn't have competition." Behold the monopoly at the apex of its power.

PNG went through that when Microsoft kept throwing incomplete and buggy support for it in IE. Hopefully something will come along to buck Chrome's monopoly and JPEG-XL will have its chance.

Re: A new PNG spec

#575

Post by jdiff »

allendoerfer wrote: post #495
jdiff wrote: post #187

Earlier quoted context omitted.

Sometimes respected, largely ignored. URLs very often don't map directly to files served.

Images almost always do.

I wish, would make my job a good bit easier. Sometimes they don't even respect format query parameters and just use whatever's in your Accept headers.

Will say though that it's not universal, it depends heavily on the corner of the internet you're on.

Re: A new PNG spec

#576

Post by colejohnson66 »

account42 wrote: post #538
colejohnson66 wrote: post #250

Earlier quoted context omitted.

Those are indeed the "magic" bytes of PNG. It's a very clever choice meant to ensure the transport layer didn't mess with it. To start, there's a byte with the upper bit set which ensures an "8-bit clean" transport. If it's stripped, it becomes a harmless tab. Then the literal "PNG" text so you can see it in a text editor. Then a CR-LF pair to check for CR-LF to LF translations. Then, a CTRL-Z to stop display on DOS-…

It's clever but I'm not so sure it actually mattered - other formats have done just as well with simpler magic numbers. All it does in the end is that you get something that doesn't identify as a PNG file rather than a PNG file with bad data when a non-binary transport is used - both results are bad and immediately apparent.

Yes and no. It wasn't just about telling you a problem occurred, but failing early and being able to say exactly why. A "something in the chain is running in 7-bit mode" is more helpful than "CRC error in IDAT". Maybe the developers were being a bit too ambitious/hopeful, but an eight byte "magic" over a "simpler" four byte one isn't really worth crying over, even with 1996 download speeds.

Re: A new PNG spec

#577

Post by fc417fc802 »

account42 wrote: post #514
fc417fc802 wrote: post #97

Earlier quoted context omitted.

All valid points, however AV1 also supports lossless compression and is almost certainly going to win the file size competition against APNG every time. https://trac.ffmpeg.org/wiki/Encode/AV1#Losslessencoding

> is almost certainly going to win the file size competition against APNG every time For video content maybe. Pixel-art gifs are not something video codecs do well at without introducing lots of artifacts.

Artifacts? We're talking about lossless compression here. There aren't any artifacts by definition.

Re: A new PNG spec

#578

Post by jcynix »

ProgramMax wrote: post #443
fwip wrote: post #440

Earlier quoted context omitted.

Do you have any examples on hand of PNGs that use the new features of the spec? It would be cool to see a little demo page with animated or HDR images, especially to download to test if our programs support them yet.

Sure! Chris Lilley--one of the original PNG co-authors--has a post with an example HDR image: https://svgees.us/blog/cICP.html It is about half way down, with the birthday cake. Generally, us tech nerds have phones that are capable of displaying it well. So perhaps view the page on your phone. What you should look for is the cake, the pink tips in her hair, and the background being more vivid. For me, the pink in the…

> But you have a bigger point: I should have live demonstrations of those things to help people understand.

Pink can pose problems for individuals with red-green color blindness (or more exactly: color vision deficiency). So make sure that examples work for these people too. Otherwise the examples might not work for about 8% of your male viewers.

Re: A new PNG spec

#579

Post by Aachen »

wongarsu wrote: post #401
Aachen wrote: post #221

Earlier quoted context omitted.

> advanced compression (finite-state entropy, like ZStandard) I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will nev…

PNG's basic idea is to store the difference between the current pixel and the pixel above it, left of it or to the top-left (chosen once per row), then apply standard deflate compression to that. The first step basically turns gradients into repeating patterns of small numbers, which compress great. You can get decent improvements by just switching deflate for zstd

> You can get decent improvements by just switching deflate for zstd

Maybe I sounded too critical of zstd. To be clear: I use it for general-purpose compression where available, the only exception would be where eeking out the last % gain is important and slow decompression is acceptable and it has one of these patterns that Bzip2 does better in the first place

That it's better than deflate (afaik aka gzip and zlib, just with different header fields) is not surprising since that was iirc the defined goal of Zstandard project

Re: A new PNG spec

#580

Post by HakanAbbas »

boogerlad wrote: post #566
HakanAbbas wrote: post #564

Earlier quoted context omitted.

Storage is cheaper than it used to be. Bandwidth is also cheaper than it used to be (though not as cheap as storage). So high quality lossy techniques and lossless techniques can be adopted more than low quality lossy compression techniques. Today, processor cores are not getting much faster. And energy is still not cheap. So in all my work, processing speed (energy consumption) is a much higher priority for me.

You're right, but aren't you forgetting that for each image, the encode cost needs to be paid just once, but the decode time must be paid many many times? Therefore, I think it's important to optimize size and decode time.

HALIC's decode speed is already much faster compared to other codecs. When you look at the compression ratios, they are almost the same. There doesn't seem to be a problem with this. There are also issues where encode speed is especially important. But I think there is no need to spend a lot more energy to make a few percent more compression and decode it.
Post reply on HN