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

301–310 of 622 posts

Re: A new PNG spec

#301

Post by jeroenhd »

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.

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 usual sidecar files, XMP files, are standardised (in that they follow a certain extensible XML structure) and can (and often do) include EXIF file information.

Re: A new PNG spec

#302

Post by ethan_smith »

hrydgard wrote: post #60

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?

For modern C/C++ PNG implementations, consider lodepng (header-only), stb_image/stb_image_write (single-file), or libspng (active fork focused on performance and security) as more actively maintained alternatives to libpng.

Re: A new PNG spec

#303

Post by arp242 »

lioeters wrote: post #207
poisonborz wrote: post #146

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.

> Not backwards compatible They say it's technically compatible since older image decoders should recognize the PNG file is using a different compression algorithm than the default. > Many programs already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer... This is intentionally ignoring the fact that there are countless PNG decoders out in the wild, many u…

libng seems to get regular updates? A release just a few days ago.

There's a PR for APNG: https://github.com/pnggroup/libpng/pull/706 – it seems there was some work for HDR in e.g. https://github.com/pnggroup/libpng/pull/635 as well. Related: https://github.com/pnggroup/libpng/issues/507

Re: A new PNG spec

#304

Post by skissane »

cmiller1 wrote: post #256
skissane wrote: post #174

Earlier quoted context omitted.

> there is no way for a user to tell from the look of the port or the file extension what the capabilities are But that's typical for file extensions. Consider EXE – it is probably an executable, but an executable for what? Most commonly Windows – but which Windows version will this EXE run on? Maybe this EXE only works on Windows 11, and you are still running Windows 10. Or maybe you are running x86-64 Windows, but…

> Consider EXE – it is probably an executable, but an executable for what? Most commonly Windows Has anyone ever used .exe for anything other than Windows?

Prior to Windows 95, the vast majority of PC games were MS-DOS exe files – so anyone who played any of those games (whether back in their heyday, or more recently through DOSBox) has run an MS-DOS exe. Most people who ever used Lotus 1-2-3 or WordPerfect were running an MS-DOS exe. Both products were eventually ported to Windows, but were far less popular under Windows than under DOS.

Under Windows 95/98/Me, most command line tools were MS-DOS executables. Their support for 32-bit Windows console apps was very poor, to the extent that the input and output of such apps was proxied through a 16-bit MS-DOS executable, conagent.exe

First time in my life I ever used GNU Emacs, it was an OS/2 exe. That's also true for bash, ls, cat, gcc, man, less, etc... EMX was my gateway drug to Slackware

Re: A new PNG spec

#305

Post by kllrnohj »

airstrike wrote: post #240
kllrnohj wrote: post #230

Earlier quoted context omitted.

> What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary. Performance. Rotation during rendering is often free, whereas the camera would need an intermediate buffer + copy if it's unable to change the way it samples from the sensor itself.

How is rotation during rendering free?

For anything GPU-rendered, applying a rotation matrix to a texture sample and/or frame-buffer write is trivially cheap (see also why Vulkan prerotation exists on Android). Even ignoring GPU-rendering, you always are doing a copy as part of rendering and often have some sort of matrix operation anyway at which point concatenating a rotation matrix often doesn't change much of anything.

Re: A new PNG spec

#306

Post by jeroenhd »

Geezus_42 wrote: post #165
michaelmior wrote: post #147

Earlier quoted context omitted.

> and the abysmal everyday use it gets Estimates are that 95% of Internet users have a browser that supports WebP and that ~25% of the top million websites serve WebP images. I wouldn't call that abysmal.

Great, so I can download it, but then I have to convert it to a different format before half my apps will be able to use it.

Everything I've tried supports WebPs. It took Adobe a while but even Photoshop supports the format these days.

Hell, for some software features (like stickers in some chat apps), WebP is mandatory.

HEIFF files, on the other hand...

Re: A new PNG spec

#307

Post by pmarreck »

illiac786 wrote: post #261
qwertfisch wrote: post #202

Seems a bit too late? And also, JPEG XL supports all the features and uses already advanced compression (finite-state entropy, like ZStandard). It offers lossy and lossless compression, animated pictures, HDR, EXIF etc. There is just no need for a PNG update, just adopt JPEG XL.

I really don’t get it. Why, but why? It’s already confusing as hell, why create yet another standard (variant) with no unique selling point?

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

Re: A new PNG spec

#308

Post by illiac786 »

pmarreck wrote: post #307
illiac786 wrote: post #261

Earlier quoted context omitted.

I really don’t get it. Why, but why? It’s already confusing as hell, why create yet another standard (variant) with no unique selling point?

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…

I was referring to the new PNG, not to JPEG XL.

Re: A new PNG spec

#309

Post by justincormack »

pwdisswordfishz wrote: post #272
ralferoo wrote: post #161

Earlier quoted context omitted.

One interesting thing about JPEG is that you can rotate an image with no quality loss. You don't need to convert each 8x8 square to pixels, rotate and convert back, instead you can transform them in the encoded form. So, rotating each 8x8 square is easy, and then rotating the image is just re-ordering the rotated squares.

That doesn't seem to apply to images that aren't multiples of 8 in size, does it?

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

Re: A new PNG spec

#310

Post by pornel »

meindnoch wrote: post #131
fc417fc802 wrote: post #97

Earlier quoted context omitted.

All valid points, however AV1 also supports lossless compression and is almost certainly going to win the file size competition against APNG every time. https://trac.ffmpeg.org/wiki/Encode/AV1#Losslessencoding

False, or misleading. The AV1 spec [1] does not allow RGB color spaces, therefore AV1 cannot preserve RGB animations in a bit-identical fashion. [1] https://aomediacodec.github.io/av1-spec/av1-spec.pdf

AV1 supports YCoCg, which encodes RGB losslessly.

It is a bit-reversible rotation of the RGB cube. It makes the channels look more like luma and chroma that the codec expects.

Post reply on HN