Live data from Hacker News

A new PNG spec

programmax.net

481–490 of 622 posts

Re: A new PNG spec

#481
post #454

Earlier quoted context omitted.

Thank you for the examples. I tried the one with a pink cake. Turns out that on my machine only web browsers are capable of displaying the image properly. All viewers (IrfanView, XnView, Nomacs, Windows Photos) and editors (Paint .NET, GIMP) that I've tried only showed the "washed out" picture.

Yeah. We were able to get buy-in from some big players. We cannot contact every group, though. My hope is since big players have bought in, others will hear the message and update their programs. Sooooo file some bugs :D Also, be kind to them. This literally launched yesterday.

The creator of photopea.com is very responsive to user suggestions. I’d recommend contacting him if you haven’t already.

Re: A new PNG spec

#482

Earlier quoted context omitted.

> many gifs these days are actually served as soundless videos That's not really true. Some websites lie to you by putting .gif in the address bar but then serving a file of a different type. File extensions are merely a convention and an address isn't a file name to begin with so the browser doesn't care about this attempt at end user deception one way or the other.

You said that's not really true and the described exactly how it's true, what did you mean?

I parsed the comment as something along the lines of clever hackers somehow stuffing soundless videos into gif containers which is most certainly not what is going on. I was attempting to convey that they have nothing to do with gifs. Gifs are not involved anywhere in the process.

I'm not sure why people disagree so strongly with what I wrote. Worst case scenario is that it's a slightly tangential but closely related rant about deceptive web design practices. Best case scenario is that someone who thought some sort of fancy trick involving gifs was in use learns something new.

Re: A new PNG spec

#483

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.

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 texture…

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

What does it say? That they are naive or have the wrong priorities? Their rationale for this seems quite reasonable to me: https://www.w3.org/TR/PNG-Rationale.html#R.Non-premultiplied...

Re: A new PNG spec

#484
post #159
post #120

Earlier quoted context omitted.

> Animated PNGs can't beat GIF nevermind video compression algorithms. Not entirely true, it depends on what's being displayed, see a few simple tests specifically constructed to show how much better APNG can be vs GIF and {,lossy} webp: http://littlesvr.ca/apng/gif_apng_webp.html Of course I don't think it generalizes all that well…

I tried these examples on ezgif, and indeed apng manages to be smaller than webp every single time. Weird, I was under the impression that webp was almost always smaller? Is this because GIF images are already special, or apng uses better compression than png? edit: using the same ezgif webp and apng on a H.264 source, apng is suddenly 10x the size than webp. It seems apng is only better if the source is gif

I would guess that apng only wins when indexed colors can be used. That guess would match what you saw using an h264 file for the source.

Re: A new PNG spec

#485
post #10

> Officially supports Exif data Probably the best news here. While you already can write custom data into a header, having Exif is good. BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.

Yes, but websites frequently strip all or almost all Exif data from uploaded images because some fields are used by stalkers to track people down to their real address.

That reminds me when I first uploaded a picture to some forum and it showed my full home address together with a map as a "feature"

Re: A new PNG spec

#486

Earlier quoted context omitted.

Which makes sense for an app made for photos: why would you capture a photograph to disk in a format made for distributing on the web?

Instagram hasn't even been primarily or even secondarily about photos for a long time. Indeed trying to "just" upload a photo is made super inconvenient these days.

Tangentially related but Instagram is really the worst plattform for photos. I don't understand why they crop and downsize (!) pictures. Not even Twitter does this, it's unironically a better photo plattform.

Re: A new PNG spec

#487
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…

I never realized how limited sRGB is. I guess this is why people liked CRT TVs, and why you could never watch analog TV properly on a PC screen.

Re: A new PNG spec

#488

Earlier quoted context omitted.

IIRC (been a while), the reason was ICCv2/v4 still requires a gamma function. And PQ is not a gamma function. Maybe they can cover HLG, but if we want to represent any given HDR content, we needed something more than ICCv2/v4.

That doesn't sound quite right to me. ICCv2's 'curveType' gives the option of a full lookup table instead of a simple gamma function. Maybe it has to do with ICCv2 saying that the reference viewing condition has an illumination level of 500 lx for the perceptual intent? (But how does that apply to non-reflective media?) I don't doubt that there's lots of problems in the chain from RGB samples to display output, but I…

Agreed that it gets confusing. That's a piece of why I'm unable to give you a solid answer. This isn't my area of expertise.

Here is what I can tell you confidently: The original plan was to provide an ICC profile that approximates PQ as best as we could. But it wasn't enough. So the proposal was to force the profile name to be a special string. When a PNG decoder saw that name, it would ignore the ICC profile and do actual PQ.

Here is that original proposal: https://w3c.github.io/png-hdr-pq/

Possibly more context (I just found this) from Apple. I'm not sure of date: https://www.color.org/hdr/02-Luke_Wallis.pdf Slide 29: "HDR parametric transfer functions not in ICC spec Parametric 3D tone mapping functions not in ICC spec - Neither can be approximated by 1-D or 3-D LUTs"

I'm not sure why they cannot be approximated by LUT. Maybe because of the inversion problem?

Re: A new PNG spec

#489
post #36

Earlier quoted context omitted.

I doubt it, given png is a lossless compression format. For video thats almost never what you want.

For animations with lots of regions of solid color it could do very well.

So do most other video formats. I'm not really seeing any advantages, and I see a lot of disadvantages vs h264 and friends.

Re: A new PNG spec

#490
post #10

> Officially supports Exif data Probably the best news here. While you already can write custom data into a header, having Exif is good. BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.

Ages ago I worked on photogrammetry software, and the lack of such information was indeed painful for us. One of the most important parts of the processing pipeline is calculation the position and orientation of each camera; having at least the orientation would have made our life much easier.
Post reply on HN