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

521–530 of 622 posts

Re: A new PNG spec

#521

Post by account42 »

chithanh wrote: post #82
albert_e wrote: 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.

When it comes to converting small video snippets to animated graphics, I think WEBP was much better than APNG from the beginning. Only if you use GIF as intermediate format then APNG was competitive. Nowadays, AVIF serves that purpose best I think.

webm or any other non-gimped video codec would be a much better format for that use case. Unfortunately browsers don't allow those in image contexts so we are stuck with an inferior "state of the art" literally-webm-with-deliberately-worse-compression webp standard.

AVIF is only starting to become widespread so can't be used without fallback if you care about your users. Not sure how it compares to AV1 quality/compression wise but hopefully its not as gimped as webp and there will encoders that aren't as crap as libwebp that almost everyone uses.

Re: A new PNG spec

#522

Post by account42 »

bawolff wrote: post #154
bmacho wrote: post #50

Earlier quoted context omitted.

> Curious if Animated SVGs are also a thing. SVG is just html5, it has full support for CSS, javascript with buttons, web workers, arbitrary fetch requests, and so on (obviously not supported by image viewers or allowed by browsers).

Browsers support all that sort of thing, as long as you use an iframe. (Technically there are sone subtle differences between that and html5, but you are right its mostly the same) If you use an tag, svgs are loaded in "restricted" mode. This disables scripting and external resources. However animation via either SMIL or CSS is still supported.

And non-browser image renders support almost none of those advanced totally-still-SVG features (and I don't blame them) while they often do support animated GIFs.

Re: A new PNG spec

#523

Post by account42 »

bawolff wrote: post #158
jokoon wrote: post #105

Earlier quoted context omitted.

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

PNG uses deflate (same as zip) but GIF uses LZW. These are different algorithms. You should expect different compression results i would assume.

ZIP is theoretically a generic container and theoretically supports a number of different compression formats. Stored (no compression) and deflate are the only ones you can count on being supported everywhere though so in practice you're not wrong.

Re: A new PNG spec

#524

Post by dspillett »

naikrovek wrote: post #228
dspillett wrote: post #199

Earlier quoted context omitted.

Because the creator of gifs telling the world how he pronounced it made such a huge difference :) Not sure I'll bother to reprogram myself from “png”, “pung”, or “pee-enn-gee”.

When someone makes a baby, you call that person by their real name with the correct pronunciation, don’t you? So why can’t you do that with GIF or PNG? People that create things get to name them.

There is a huge difference between inanimate objects/classes and babies. Don't personify inanimate objects, they hate that!

On inanimate objects: Aluminium was first ratified by the IUPAC as aluminium⁰, with the agreement of its discoverer Sir Humphrey Davy¹, yet one huge nation calls it something else…

On people: nicknames are a thing, are you saying those are universally wrong? But yes, when a person tells me that they'd prefer their name pronounced a different way, or that they'd prefer a different name entirely, or that they don't like the nickname other use for them, you can bet your arse that I'll make the effort to use their preferred name+pronunciation in future.

------

[0] Though it should be noted that aluminum was, a few years after, officially accepted as an alternate form.

[1] He initially called it aluminum in the first paper.

Re: A new PNG spec

#525

Post by account42 »

Calzifer wrote: post #179
jokoon wrote: post #105

Earlier quoted context omitted.

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

(A)PNG supports semi-transparency. In GIF a pixel is either full transparent or full opaque. Also while true color gifs seem to be possible it is usually limited to 256 colors per image. For those reasons alone APNG is much better than GIF.

> Also while true color gifs seem to be possible it is usually limited to 256 colors per image.

No, it's limited to 256 colors per frame and frames can have duration 0 which allows you to combine multiple frames into more than 256 color images.

Re: A new PNG spec

#526

Post by account42 »

dylan604 wrote: post #318
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…

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

Yes the whole point of lossless re-compression is that you do not need to keep the original JPEGs. Of course you don't need to "purge" backups, just let them rotate out normally.

Also backup storage is usually cheaper than something that needs to have fast access speeds.

Re: A new PNG spec

#527

Post by account42 »

rhet0rica wrote: post #449
mikae1 wrote: post #345

Earlier quoted context omitted.

> There is just no need for a PNG update, just adopt JPEG XL. Tell that to Google. They gave up on XL in Chrome[1] and essentially killed its adoption. [1] https://issues.chromium.org/issues/40168998#comment85

From reading that, "gave up" seems to mean "deliberately killed it so their own WebP2 wouldn't have competition." Behold the monopoly at the apex of its power.

The really weird part is that both webp and jxl developments were largely funded by Google so its not Google killing a competitors format over their own but someone in one part of Google killing the format someone elsewhere in Google developed over their pet favorite.

Re: A new PNG spec

#528

Post by account42 »

kccqzy wrote: post #296
ggm wrote: post #45

Earlier quoted context omitted.

It's in sidecar files. Takeout gets them, some tools read them.

But there is no standardization of sidecar files, no? Whereas EXIF is pretty standard.

XMP [0] is a standard but no idea of Google and Apple use it (Darktable does). You could also store EXIF data as sidecar files but I don't think that has better support.

[0] https://en.wikipedia.org/wiki/Extensible_Metadata_Platform

Re: A new PNG spec

#529

Post by account42 »

SchemaLoad wrote: post #457
jeroenhd wrote: post #301

Earlier quoted context omitted.

EXIF inside of PNGs is new. You can make it work by embedding structured chunks into the file, but it's not official in any way (well, not until the new spec, at least). Sidecar files have some kind of interoperable format that at least don't break buggy PNG parsers when you open the image file. The sidecar files themselves differ in format, but at least they're usually formatted according to their extension. The usu…

Pretty much all the photos in Apple/Google photos are going to be JPEG and HEIF which do support EXIF. But both services basically will not touch what came out of the camera at all. If you add a description or date, it gets stored externally to the image so when you export your data, those changes are lost. Or they get dumped in a JSON file requiring you to use some custom script to handle it.

Not touching the image for metadata changes is a good thing as that makes backups more efficient/simpler. Embedded metadata is also a security issue as users may share more information than they realize which is why it is common to strip it automatically in many places.

Re: A new PNG spec

#530

Post by dspillett »

npteljes wrote: post #420
LocalH wrote: post #334

Earlier quoted context omitted.

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 have the same experience - but with gif . Mind you, me and my circle are not native English speakers. The debate itself is old. "Since the 90s" Wikipedia says, and keep in mind the format was is from 1987 - so I would say the debate is on from the get-go. Appropriate, too, if you think back, arguing about this kind of stuff was pretty common. Emacs vs vim, browser wars, different kinds of computers, tribalism every…

I think “since the 90s” here is “since the late 90s”. When I first was aware of gif files (in the early 90s IIRC) I only saw the name and meaning in print so went with the hard G to match the g's pronunciation in graphics, I don't think I was aware of the original intention to pronounce it jif until somewhere in the early 2000s, at which point the use of the hard g was almost ubiquitous and the soft g idea was presented as an interesting/amusing aside.
Post reply on HN