Live data from Hacker News

A new PNG spec

programmax.net

391–400 of 622 posts

Re: A new PNG spec

#391

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

Worry not! (Well, worry a little.)

The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?"

Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option.

Here's the worry-a-little part: Everybody immediately jumps to file size as to what image compression is better or worse. That isn't the best take, but it is what it is. So there is pressure to adopt newer technologies.

We often do have a way to maintain some degree of backwards compatibility even when we do this. For example, we can store a downsampled image for old viewers. Then extra, new chunks will know "Mix that with this full scale data, using a different compression".

As you can imagine, this mixing complicates things. It might not be the best option. Sooooo we're researching it :)

Re: A new PNG spec

#392
post #334

Earlier quoted context omitted.

As much as I hate jif , thinking about it, "GPU" works the same - we say gee-pee-you and not gh-pee-you . Garbage Collection is also gee-cee . So it's only logical that jif is the correct one - even if it's not the widely accepted one. Wrt/ communication, aside from personal preference, one can either respect the creator, or the audience. If I stand in front of 10 colleagues, 10 out of them would not understand jif ,…

The whole debate seems to be a modern phenomenon to me - from my anecdotal experience back in the day, it was never questioned by computer enthusiasts that it was pronounced "jif".

I (as a non-native English speaker) have pronounced it with a hard g since first i saw it (mid ’90s) and many years before I learned how the creator preferred it to be pronounced.

I continue to pronounce it how I prefer it, not as a slight, but most people here would be surprised by the soft g.

If I ever meet him I’ll attempt to pronounce it soft-g.

On the other hand, even though my name exists and is reasonably common in English, I’m fairly certain neither you or the GIF creator would address me the way I pronounce my name. I would understand anyway, and wouldn’t care one bit.

Re: A new PNG spec

#393
post #324

So what do we call it? PNG3? The spec is titled "Portable Network Graphics Specification (Third Edition)". Surely they aren't releasing a new, incompatible version and expecting us to pretend it's the same format...? > This updates the existing image/png Internet Media type whyyyyyyy

New? Yes. Incompatible? No.

We went to pretty extreme lengths to make sure old software worked with the new changes. Effectively, the limit will be the software, not the image.

For example, you can imagine some old software that is unaware of color spaces and treats everything as sRGB. There is nothing we can do to make that software show a Display P3 correctly. However, we can still show the image well enough that a user understands "that is a red apple".

Re: A new PNG spec

#394
post #360

Earlier quoted context omitted.

I can tell you, I have personally worked with a global corporation and we estimated that for one of their websites, supporting the 3% that we exclude by using “modern standards” would be more costly than the amount of revenue they get from them. So in that case, it was a rational decision. And up to the 10% cut, management just didn’t want to do the extra investment. So if something falls below that 10% threshold, th…

Something is off in this calculation, how did they get to such a high cost for such a simple thing as an alternative image format when the web supports multiple???

My guess would be that the users hitting different types of issues are mostly the same; someone who can't view an alternative image format is using an obscure old browser or obscure OS that will inevitably have a ton of other issues too, and fixing only a subset of the issues would not make much difference.

Re: A new PNG spec

#395

Not backwards compatible. We just add it to that nice cupboard "great advanced image formats we will forget about". Society doesn't need a new image format. I'd wager to say not any new multimedia format. Big corporate entites do, and have churning them out at a steady pace. Look at poor webp - a format pushed by the largest industry players - and the abysmal everyday use it gets, and the hate it generates.

It is very backwards compatible. I'm not sure why you thought that.

We jumped through quite a lot of hoops to make sure old software will be able to display new images. They simply won't display them optimally. But for the most part, that would be because the old software wouldn't display images optimally anyway. So the limit was the software, not the format.

What I mean by this is old software that treats everything as sRGB wouldn't correctly show a Display P3 image anyway. But we made sure it will still display the image as correctly as it could.

Re: A new PNG spec

#396

Earlier quoted context omitted.

> Curious if Animated SVGs are also a thing. Yes. Relevant animation elements: • • • • See https://www.w3schools.com/graphics/svg_animation.asp

Oh TIL - Thanks! This could possibly be used to build full fledged games like pong and breakout :)

SVG also supports Javascript, which will probably be a lot more useful for games.

Re: A new PNG spec

#397

What about implementations? libpng seems pretty dead, 1.7 has been in development forever but 1.6 is still considered the stable version. Is there a current "canonical" png C/C++ library?

libpng updates are either already landed or nearly landed.

Re: A new PNG spec

#398

Earlier quoted context omitted.

Without the new HDR and color profile handling, PNG was still useful but significantly obsolete. Display hardware has progressed over a few decades, raising the bar for image files.

PNG already supports color profiles, but probably not HDR. I would say that the gamut argument in the article is misleading, you can already encode a wider gamut. Not sure how HDR encoding works, but my impression is that you can set a nominal white point other than (1, 1, 1) in your specified colorspace. This is an extension, but orthogonal to specifying the colorspace itself and the gamut.

You are correct. I designed the article to be very approachable and understandable for the normal person. As such, I took some liberties like only showing HDR primaries and ignoring transfer function. I linked to Chris Lilley's post to give experts a more correct answer.

But wide color gamut was already possibly in PNG via ICC profiles (HDR was not). And those primaries I showed could have been used in a wide color image.

So the image is a bit misleading or red-flag-y to experts who know. But to the average person, I think it is as truthful as I can be without getting too deep in the weeds.

Re: A new PNG spec

#399

Earlier quoted context omitted.

the stored image is always a multiple of 8, with padding that is ignored (and heavily compressed).

But can this lossless rotation process account for padding not being in the usual place (lower right corner presumably)?

I'm not sure if this is how JPEG implements it, but in H.264, you just have metadata which specifies a crop (since H.264 also encodes in blocks). From some quick Googling, it seems like JPEG also has EXIF data for cropping, so if that's the mechanism that's used to crop off the bottom and right portions today, there's no reason it couldn't also be used to crop off the top and left portions when losslessly rotating an image's blocks.

Re: A new PNG spec

#400
post #75

it's more to do with the obvious economic layer underneath. you give a format new life only if there's tooling and distribution muscle behind it. adobe, apple, chrome, ffmpeg etc may not get aligned at the same time. someone somewhere wants apng/hdr/png to be a standard pipe again for creative chains; maybe because video formats are too bulky for microinteraction or maybe because svg is too unsafe in sandboxed render…

In general, I support the "follow the money" idea. But I don't think it applies here.

I'm retired and making zero money here. (I'm actually losing money on it. Wish I had a company sponsoring me for the flights and hotels for meetups.)

All participants are required to not patent any piece of it. We work hard to make sure we only reference open standards. (This one is quite tricky. We have to convince other standard orgs to make their stuff free.)

I could see the argument for getting around a gate. But fwiw I don't think that's the case :)

Post reply on HN