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

311–320 of 622 posts

Re: A new PNG spec

#311

Post by voxleone »

ksec wrote: post #170

It is just a spec on something widely implemented already. Assuming Next gen PNG will still require new decoder. They could just call it PNG2. JPEG-XL already provides everything most people asked for a lossless codec. If there are any problems it is its encoding and decoding speed and resources. Current champion of Lossless image codec is HALIC. https://news.ycombinator.com/item?id=38990568

I'm using png in a computer vision image annotation tool[0]. The idea is to store the class labels directly in the image [dispensing with the side car text files], taking advantage of the beautiful png metadata capabilities. The next step is to build a specialized extension of the format for this kind of task.

[0]https://github.com/VoxleOne/XLabel

Re: A new PNG spec

#312

Post by illiac786 »

ksec wrote: post #273
illiac786 wrote: post #263

Earlier quoted context omitted.

> If there are any problems it is its encoding and decoding speed and resources. And this will improve over time, like jpg encoders and decoders did.

I hope I am very wrong but this isn't given. In the past reference encoder and decoder do not concern about speed and resources, but last 10 years have shown most reference encoder and decoder has already put considerable effort into speed optimisation. And it seems people are already looking to hardware JPEG XL implementation. ( I hope and guess this is for Lossless only )

I would agree we will see less improvements that when comparing modern jpeg implementation and the reference one.

When it comes to hardware encoding/decoding, I am not following your point I think. The fact that some are already looking at hardware implementation for JPEG XL means that….?

I just know JPEG hardware acceleration is quite common, hence I am trying to understand how that makes JPEG XL different/better/worse?

Re: A new PNG spec

#314

Post by pornel »

bigfishrunning wrote: post #299
bawolff wrote: post #151

Earlier quoted context omitted.

Its also because people like to "pause" animations, and that is not really an option with apng & gif.

why not? that's up to the program displaying the animation, not the animation itself -- i'm sure a pausable gif or apng display program is possible

It's absolutely possible. Browsers even routinely pause playback when images aren't visible on screen.

They just don't have a proper UI and JS APIs exposed, and there's nothing stopping them from adding that.

IMO browsers are just stuck with tech debt, and maintainin a no-longer-relevant distinction between "animations" and "videos". Every supported codec should work wherever GIF/APNG work and vice versa.

It's not even a performance or complexity issue, e.g. browsers support AVIF "animations" as images, even though they're literally fully-featured AV1 videos, only wrapped in a "pretend I'm an image" metadata.

Re: A new PNG spec

#315

Post by BobaFloutist »

pmarreck wrote: post #307
illiac786 wrote: post #261

Earlier quoted context omitted.

I really don’t get it. Why, but why? It’s already confusing as hell, why create yet another standard (variant) with no unique selling point?

JPEG XL is not a "variant", it is a completely new algorithm that is also fully backwards-compatible with every single JPEG already out there, of which there are probably billions at this point. It also has pretty much every feature desired in an image standard. It is future-proofed. You can losslessly re-compress a JPEG into a JPEG-XL file and gain space. It is a worthy successor (while also being vastly superior to…

Is there any risk that if I open a JPEG-XL in something that knows what a JPEG is but not what a JPEG-XL is and then save it, it'll get lossy compressed? Backwards compatibility is awesome, but I know that if I save/upload/share/copy a PNG, it shouldn't change without explicit edits, right?

Re: A new PNG spec

#317

Post by pornel »

jeroenhd wrote: post #106
armada651 wrote: post #81

Earlier quoted context omitted.

> Can animated PNG beat av1 or whatever? Animated PNGs can't beat GIF nevermind video compression algorithms.

Once you add more than 256 different colours in total, GIF explodes in terms of file size. It's great for small, compact images with limited colour information, but it can't compete with APNG when the image becomes more detailed than what you'd find on Geocities.

No, APNG explodes in size in that case.

In APNG it's either the same 256 colors for the whole animation, or you have to use 24-bit color. That makes the pixel data 3 times larger, which makes zlib's compression window effectively 3 times smaller, hurting compression.

OTOH GIF can add 256 new colors with each frame, so it can exceed 256 colors without the cost of switching all the way to 16.7 million colors.

Re: A new PNG spec

#318

Post by dylan604 »

pmarreck wrote: post #307
illiac786 wrote: post #261

Earlier quoted context omitted.

I really don’t get it. Why, but why? It’s already confusing as hell, why create yet another standard (variant) with no unique selling point?

JPEG XL is not a "variant", it is a completely new algorithm that is also fully backwards-compatible with every single JPEG already out there, of which there are probably billions at this point. It also has pretty much every feature desired in an image standard. It is future-proofed. You can losslessly re-compress a JPEG into a JPEG-XL file and gain space. It is a worthy successor (while also being vastly superior to…

> 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?

Re: A new PNG spec

#319

Post by yyyk »

ksec wrote: post #170

It is just a spec on something widely implemented already. Assuming Next gen PNG will still require new decoder. They could just call it PNG2. JPEG-XL already provides everything most people asked for a lossless codec. If there are any problems it is its encoding and decoding speed and resources. Current champion of Lossless image codec is HALIC. https://news.ycombinator.com/item?id=38990568

When it comes to metadata, an implementation not being widely implemented (yet) is not that big a problem. Select tools will do for meta, so this is an advancement for PNG.

Re: A new PNG spec

#320

Post by sdenton4 »

illiac786 wrote: post #308
pmarreck wrote: post #307

Earlier quoted context omitted.

JPEG XL is not a "variant", it is a completely new algorithm that is also fully backwards-compatible with every single JPEG already out there, of which there are probably billions at this point. It also has pretty much every feature desired in an image standard. It is future-proofed. You can losslessly re-compress a JPEG into a JPEG-XL file and gain space. It is a worthy successor (while also being vastly superior to…

I was referring to the new PNG, not to JPEG XL.

Looking at TFA, it's placing in the spec a few things that are already widely stacked onto the format (such as animation). This is a very sensible update, and backwards compatible with existing PNG.
Post reply on HN