Live data from Hacker News

A new PNG spec

programmax.net

101–110 of 622 posts

Re: A new PNG spec

#101
post #91

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.

>Display hardware has progressed It has, but WWW is still de facto sRGB, and will be for a long time still. But again, I'm not strictly opposed to evolving PNG, I just hope they don't ruin it in the process, because that's usually what happens when something gets update for a modern audience . I'll be watching with mixed optimism and concern.

Plenty of JPGs on the web are already in HDR and you wouldn't notice it if you don't have a HDR capable display. The same is true for PNGs.

Re: A new PNG spec

#102
post #73

Earlier quoted context omitted.

Yea I'm mildly concerned about this as well. PNG's age is a feature, in a time where software development has gone to hell.

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.

> Display hardware has progressed

The continued popularity of non-HDR 1080p screens on laptops is a bleak reminder that most people would rather save a couple hundred bucks than buy HDR capable hardware.

HDR is great for TVs and a nice-to-have on phones (who mostly get it for free because OLEDs are the norm these days), but display technology only advances as much as its availability in low-cost devices.

Re: A new PNG spec

#103
post #73

Earlier quoted context omitted.

Yea I'm mildly concerned about this as well. PNG's age is a feature, in a time where software development has gone to hell.

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.

Re: A new PNG spec

#104

DaVinci Resolve also supports OpenEXR format with the added magic of LUT. PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases. Even after spending a few grand on seats for a project, one still gets arrogant 3D clown-ware vendors telling people how they should run their pipeline with PNG hot garbage as input. People should choose EXR…

"PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases." What are you talking about? It's a bitmap. It has nothing to do with "exposure and color problems."

In general, with some applications people hit the limits pretty quickly with PNG and JPG. In our use-case, the EXR format essentially meant a rendered part of the source image wouldn't be "overexposed" by the render pipeline, and layers could be later adjusted to better match in Resolve. Example: your scenes fireball simulation won't look like a fried egg photo from 1980 due to hitting 0xFF.

If you've never encountered the use-case, than don't worry about the aesthetics. Seriously, many vendors also just don't care... especially after they already were paid. Best of luck =3

Re: A new PNG spec

#105
post #5

So animated GIFs can be replaced by Animated PNGs with alpha blending with transparent backgrounds and lossless compression! Some nostalgia from 2000s websites can be revived and relived :) Curious if Animated SVGs are also a thing. I remember seeing some Javascript based SVG animations (it was a animated chatbot avatar) - but not sure if there is any standard framework.

both GIF and PNG use zipping for compressing data, so APNG are not much better than GIF

Re: A new PNG spec

#106

Earlier quoted context omitted.

I was under the impression many gifs these days are actually served as soundless videos, as those basically compress better. Can animated PNG beat av1 or whatever?

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

Re: A new PNG spec

#107

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

Better compression can also mean a new set of filter methods or a new interlacing algorithm. But yeah, any of them would cause an instant incompatibility. As noted in the relevant issue [1], we will need a new media type at the very least. [1] https://github.com/w3c/png/issues/39#issuecomment-2674690324

I am hopeful whatever better compression doesn't end up multiplying memory requirements, or increase burden on cpu, especially on decompression.

Now, PNG datatype for AmigaOS will need upgrading.

Re: A new PNG spec

#108

Earlier quoted context omitted.

Exif can also cause confusion for how to render the image: should its rotation be applied or not? Old decoders and new decoders now could render an image with exif rotation differently since it's an optional chunk that can be ignored, and even for new decoders, the spec lists no decoder recommendations for how to use the exif rotation It does say "It is recommended that unless a decoder has independent knowledge of t…

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!

Re: A new PNG spec

#109
post #73

Earlier quoted context omitted.

Yea I'm mildly concerned about this as well. PNG's age is a feature, in a time where software development has gone to hell.

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.

There is nothing in display hardware today that TIFF couldn't handle already.

For example 16bit (integer) TIFF files 'with headroom', i.e. where some bits were used to represent data over 1.0 (HDR) was a common approach for VFX work in the 90's.

16bit float TIFF is also thing since 33 years. Adobe DNG is modeled after TIFF. High end offline renderers have traditionally been using TIFF (with mip-maps) to store textures.

TIFF supports tags so primaries and white point or a known color space name can be stored in the file.

The format is so versatile, it is used everywhere.

And of course it also supports indexed color, i.e. a non-negotiable feature at the time PNG was introduced.

PNG was meant to replace GIF. Instead of looking what was already there some group of "experts" and "enthusiasts" (quote Wikipedia) succumbed to their NIH complexes. If licensing/patent woes over compression algorithms had been a motivator, why not just add a new one to TIFF?

The fact that PNG stores straight/unpremultiplied alpha says everything if you know anything about imaging in computer graphics.

And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today.

PNG is the VHS of image formats. It should have never seen the light day of in the first place nor the adoption it did.

Re: A new PNG spec

#110
post #98
post #24

Earlier quoted context omitted.

> Having an extensible format and electing never to extend it seems pointless. This proves OP analogy regarding USB-C. Having PNG as some generic container for lossless bitmap compression means fragmentation in libraries, hardware support, etc. The reason being that if the container starts to support too many formats, implementations will start restricting to only the subsets the implementers care about. For instance…

I never once in 25 years encountered an issue with an mp4 Container that could Not be solved by installing either the divx or xvid codec. And I extensively used mp4's metatdat for music, even with esoteric Tags. Not Sure what youre talking abouz.

He's saying that in 25 years, you used only the LC and HE profiles, and didn't encounter TwinVQ even once. I looked at my thousand-odd MPEG-4 files. They're overwhelmingly AAC LC, a little bit of AAC LC SBR, no TwinVQ at all.

If you want to check yours: mediainfo **/*.mp4 | grep -A 2 '^Audio' | grep Format | sort | uniq -c

https://en.wikipedia.org/wiki/TwinVQ#TwinVQ_in_MPEG-4 tells the story of TwinVQ in MPEG-4.

Post reply on HN