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

111–120 of 622 posts

Re: A new PNG spec

#111

Post by jillesvangurp »

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 new files. And teaching people that sRGB maybe isn't good enough any more. That's going to be hard since most people have no clue about color spaces.

Anyway, that gives everybody plenty of time to upgrade. By the time this stuff is widely used, it will be widely supported. So, you kind of get forward compatibility that way. Your browser already supports the new format. Your image editor probably doesn't.

Re: A new PNG spec

#112

Post by bspammer »

johnisgood wrote: post #63
jandrese wrote: post #19

Earlier quoted context omitted.

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.

And I strip Exif data, too, intentionally, for similar reasons.

That makes sense to me for any image you want to share publicly, but for private images having the location and capture time embedded in the image is incredibly useful.

Re: A new PNG spec

#113

Post by Xss3 »

voidUpdate wrote: post #65
yoz-y wrote: post #47

Earlier quoted context omitted.

The problem is not backward compatibility but labeling. A USB-C cable looks universal but isn’t. Some of them just charge, some do data, some do PD, some give you access to high speed. But there is no way to know. I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.

That's not just an issue with usb-c. normal usb a and b cables can have data or no data depending on how stingy the company wants to be, and you can't know until you test it

You can get pretty good guesses just by feel and length. Tiny with a super thin cable? Probably charge only.

Re: A new PNG spec

#114

Post by Xss3 »

globular-toast wrote: post #59
yoz-y wrote: post #47

Earlier quoted context omitted.

The problem is not backward compatibility but labeling. A USB-C cable looks universal but isn’t. Some of them just charge, some do data, some do PD, some give you access to high speed. But there is no way to know. I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.

Some aren't even USB. Thunderbolt and DisplayPort both use USB-C too.

Thunderbolt meets usbc specs (and exceeds them afaik), so it is still usb...

Re: A new PNG spec

#115

Post by Joel_Mckay »

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!

Most modern camera modules have built in hardware codecs like mjpeg, region of interest selection, and frame mirror/flip options.

This is particularly important on smartphones and battery operated devices. However, most smartphone devices simply save the photo the same way regardless of orientation, and simply add a display-rotated flag to the metadata.

It can be super annoying sometimes, as one can't really disable the feature on many devices. =3

Re: A new PNG spec

#116

Post by Xss3 »

lelanthran wrote: post #94
mystifyingpoi wrote: post #58

Earlier quoted context omitted.

Cable labeling could fix 99% of the issues with USB-C compat. The solution should never be blaming consumer for buying the wrong cable. Crappy two-wire charge-only cables are perfectly fine for something like a night desk lamp. Keep the poor cables, they are okay, just tell me if that's the case.

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

Re: A new PNG spec

#117

Post by cm2187 »

koito17 wrote: post #24
Lerc wrote: post #15

Earlier quoted context omitted.

It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.

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

But where the analogy with USB-C is very good is that just like USB-C, there is no way for a user to tell from the look of the port or the file extension what the capabilities are. Which even for a fairly tech savvy user like me is frustrating. I have a bunch of cables, some purchased years ago, how do I know what is fit for what?

And now think of the younger generation that has grown up with smartphones and have been trained to not even know what a file is. I remember this story about senior high school students failing their school tests during covid because the school software didn't support heif files and they were changing the file extension to jpg to attempt to convert them.

I have no trust the software ecosystem will adapt. For instance the standard libraries of the .net framework are fossilised in the world of multimedia as of 2008-ish. Don't believe heif is even supported to this day. So that's a whole bunch of code which, unless the developers create workarounds, will never support a newer png format.

Re: A new PNG spec

#118

Post by clownpenis_fart »

snvzz wrote: post #107
lifthrasiir wrote: post #7

Earlier quoted context omitted.

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.

[dead]

Re: A new PNG spec

#119

Post by Arnt »

lifthrasiir wrote: post #7
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.

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

We would need a new media type. But the actual new features don't need one, because the news don't break compatibility.

https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the new colour space. If your software and monitor can handle it, you see better colour than I, otherwise, you see what I see.

Re: A new PNG spec

#120

Post by Aissen »

armada651 wrote: post #81
riffraff wrote: post #12

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.

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

Post reply on HN