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

131–140 of 622 posts

Re: A new PNG spec

#131

Post by meindnoch »

fc417fc802 wrote: post #97
layer8 wrote: post #44

Earlier quoted context omitted.

APNG would be for lossless compression, and probably especially for animations without a constant frame rate. Similar to the original GIF format, with APNG you explicitly specify the duration of each individual frame, and you can also explicitly specify looping. This isn’t for video, it’s more for Flash-style animations, animated logos/icons [0], or UI screen recordings. [0] like for example these old Windows animati…

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

False, or misleading.

The AV1 spec [1] does not allow RGB color spaces, therefore AV1 cannot preserve RGB animations in a bit-identical fashion.

[1] https://aomediacodec.github.io/av1-spec/av1-spec.pdf

Re: A new PNG spec

#132

Post by hnlmorg »

jillesvangurp wrote: post #111
LeoPanthera wrote: post #3

> I know you all immediately wondered, better compression?. We're already working on that. This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files. It'll be like USB-C but for images.

Old PNGs will work just fine. And forward compatibility is much less important. The main use case for PNG is web browsers and all of them seem to be on board. Using old web browsers is a bad idea. You do get these relics showing up using some old version of internet explorer. But some images not rendering is the least of their problems. The main challenge is actually going to be updating graphics tools to export the…

Browsers aren't the only software that work with PNGs. Far from it in fact.

Re: A new PNG spec

#133

Post by Aardwolf »

mavhc wrote: post #108
DidYaWipe wrote: post #85

Earlier quoted context omitted.

The stupid thing is that any device with an orientation sensor is still writing images the wrong way and then setting a flag, expecting every viewing application to rotate the image. The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF.

Because your non-smartphone camera doesn't have enough ram/speed to do that I assume (when in burst mode) If a smartphone camera is doing it, then bad camera app!

Rotation for speed/efficiency/compression reasons (indeed with PNG's horizontal line filters it can have a compression reason too) should have been a flag part of the compressed image data format and for use by the encoder/decoder only (which does have caveats for renderers to handle partial decoding though... but the point is to have the behavior rigorously specified and encoded in the image format itself and handled by exactly one known place namely the decoder), not part of metadata

It's basically a shame that the exif metadata contains things that affect the rendering

Re: A new PNG spec

#134

Post by ajnin »

LeoPanthera wrote: post #3

> I know you all immediately wondered, better compression?. We're already working on that. This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files. It'll be like USB-C but for images.

What backward compatibility are we talking about here? Backwards compatibility of images will be fine, backwards compatibility of decoders might be impacted, but the article says the major image viewers (browsers) and image editors already support the 3rd version. Better compression is only planned for the 5th version of the spec.

Also if you forbid evolving existing formats, the only alternative to improve is to introduce a new format, and I argue that it would be causing even more fragmentation and be more difficult to adopt to. Look at all the drama surrounding JPEG XL.

Re: A new PNG spec

#135

Post by sylware »

Until everything new is "optional". Hopefully PNG won't be the target of "enshitification". We all know that for file formats, there is a very strong pressure from developers and vendors for that to happen since it favors, hard, vendor and developer lock-in. If not careful, even with a team of PHD devs won't be able to write alternatives encoders/decoders that "reasonbly" and the world will end-up with very few alternatives implementations, if not only one.

I did skim through the specs, it seems most of it is related to cleanup and optional blocks, so it seems PNG is still safe, am I wrong? (asking those who did dive into the new specs deeply).

Re: A new PNG spec

#136

Post by lelanthran »

Xss3 wrote: post #116
lelanthran wrote: post #94

Earlier quoted context omitted.

> Cable labeling could fix 99% of the issues with USB-C compat. Labelling is a poor band-aid on the root problem - consumer cables which look identical and fit identically should work wherever they fit. There should never have been a power-only spec for USB-C socket dimensions. If a cable supports both power and data, it must fit in all sockets. If a cable supports only power it must not fit into a power and data soc…

So since my vape (example, i dont vape) has a power and data slot for charging and firmware updates, i should be limited to only using dual purpose cables day to day rather than a power only cable?

> So since my vape (example, i dont vape) has a power and data slot for charging and firmware updates, i should be limited to only using dual purpose cables day to day rather than a power only cable?

Well, yes.

Why can't you use a power+data cable for the vape (or whichever appliance takes both)? What's the deal-breaker here?

The alternative is labeling, or plugging cables in to see if they do what you want them to do.

Both are a poor user interface.

Re: A new PNG spec

#137

Post by altairprime »

Dwedit wrote: post #92

If you wanted better compression, it's called Lossless WEBP. Lossless WEBP is such a nice codec. Compared with Lossless JXL, it decompresses many times more quickly, and while JXL usually produces a smaller file, it doesn't always. Lossless AVIF is not competitive. However, lossless WEBP does not support indexed color images. If you need palettes, you're stuck with PNG for now.

I look forward to seeing what PNG v5 does in the future with compression, especially relative to existing formats.

Re: A new PNG spec

#139

Post by ansgri »

Dwedit wrote: post #92

If you wanted better compression, it's called Lossless WEBP. Lossless WEBP is such a nice codec. Compared with Lossless JXL, it decompresses many times more quickly, and while JXL usually produces a smaller file, it doesn't always. Lossless AVIF is not competitive. However, lossless WEBP does not support indexed color images. If you need palettes, you're stuck with PNG for now.

How's HDR and high bit depth support? One of the things I liked about JXL is wide range of bit depths and arbitrary number of channels.

Re: A new PNG spec

#140

Post by altairprime »

LeoPanthera wrote: post #3

> I know you all immediately wondered, better compression?. We're already working on that. This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files. It'll be like USB-C but for images.

They could, for example, use lossy compression for the compatibility layer and then fill it in the rest of the way to lossless using incompatible new compression objects. Legacy uses will see some fidelity degradation, but they are already being stuck with sRGB downmixes, so that’s fine — and those who are bothered by it can just emit a lossless-pixels (but lossy-color and lossy-range) compatibility layer and reserve the compression benefits for the color and dynamic range.

I’m not saying this is what will happen — but if I was able to construct a plausible approach to compression in ten minutes, then perhaps it’s a bit early to predict the doom of compatibility.

Post reply on HN