A new PNG spec • Hacker News Board

Re: A new PNG spec

#381

Post by Arnt » Wed, Jun 25, 2025, 5:34 PM UTC

Findecanor wrote: post #208

Arnt wrote: post #128

Earlier quoted context omitted.

I don't see why? If your video output is plain old RGB (like the Amiga hardware), then an unmodified decoder will handle new files without a problem. You only need a new decoder if your video output can handle more vivid colours than RGB can express.

An image decoded in the wrong colour space for the output will look wrong. It is not using extra bits to express the increased dynamic range: the existing numeric range is stretched and warped.

Yes. But how bad? AIUI the way it's done is more or less the best that can be done with old video hardware, like mine and like the Amiga.

It could be horrible in principle, but actually isn't.

Re: A new PNG spec

#382

Post by neuronexmachina » Wed, Jun 25, 2025, 5:36 PM UTC

joshmarinacci wrote: post #335

A fun trick I do with my web based drawing tools is to save a JSON representation of your document as a comment field inside of a PNG. This way the doc you save is immediately usable as an image but can also be loaded back into the editor. Also means your downloads folder isn’t littered with unintelligible JSON files.

This would be great for things like exported Mermaid diagrams.

Re: A new PNG spec

#383

Post by ProgramMax » Wed, Jun 25, 2025, 5:38 PM UTC

bla3 wrote: post #342

ksec wrote: post #170

It is just a spec on something widely implemented already. Assuming Next gen PNG will still require new decoder. They could just call it PNG2. JPEG-XL already provides everything most people asked for a lossless codec. If there are any problems it is its encoding and decoding speed and resources. Current champion of Lossless image codec is HALIC. https://news.ycombinator.com/item?id=38990568

WebP lossless is close to state of the art and widely available. It's also not widely used. The takeaway seems to be that absolute best performance for lossless compression isn't that important, or at least it won't get you widely adopted.

WebP maxes at 8-bit per channel. For HDR, you really need 10- or 12-bit.

WebP is amazing. But if I were going to label something "state of the art" I would go with JPEGXL :)

Re: A new PNG spec

#384

Post by HakanAbbas » Wed, Jun 25, 2025, 5:39 PM UTC

ksec wrote: post #170

It is just a spec on something widely implemented already. Assuming Next gen PNG will still require new decoder. They could just call it PNG2. JPEG-XL already provides everything most people asked for a lossless codec. If there are any problems it is its encoding and decoding speed and resources. Current champion of Lossless image codec is HALIC. https://news.ycombinator.com/item?id=38990568

I don't really understand what the new PNG does better. Elements such as speed or compression ratio are not mentioned. Thanks also for your kind thoughts ksec.

Apart from the widespread support in codecs, there are 3 important elements: processing speed, compression ratio and memory usage. These are taken into account when making a decision (pareto limit). In other words, the fastest or the best compression maker alone does not matter. Otherwise, the situation can be interpreted as insufficient knowledge and experience about the subject.

HALIC is very good in lossless image compression in terms of speed/compression ratio. It also uses a comic amount of memory. No one mentioned whether this was necessary or not. However, low memory usage negatively affects both the processing speed and the compression ratio. You can see the real performance of HALIC only on large-sized(20 MPixel+) images(single and multi-thread). An example current test is below. During operations, HALIC uses only about 20 MB of memory, while JXL uses more than 1 GB of memory.

https://www.dpreview.com/sample-galleries/6970112006/fujifil...

June 2025, i7 3770k, Single Thread Results

----------------------------------------------------

First 4 JPG Images to PPM, Total 1,100,337,479 bytes

HALIC NORMAL: 5.143s 6.398s 369,448,062 bytes

HALIC FAST : 3.481s 5.468s 381,993,631 bytes

JXL 0.11.1 -e1: 17.809s 28.893s 414,659,797 bytes

JXL 0.11.1 -e2: 39.732s 26.195s 369,642,206 bytes

JXL 0.11.1 -e3: 81.869s 72.354s 371,984,220 bytes

JXL 0.11.1 -e4: 261.237s 80.128s 357,693,875 bytes

----------------------------------------------------

First 4 RAW Images to PPM, Total 1.224.789.960 bytes

HALIC NORMAL: 5.872s 7.304s 400,942,108 bytes

HALIC FAST : 3.842s 6.149s 414,113,254 bytes

JXL 0.11.1 -e1: 19.736s 32.411s 457,193,750 bytes

JXL 0.11.1 -e2: 42.845s 29.807s 413,731,858 bytes

JXL 0.11.1 -e3: 87.759s 81.152s 402,224,531 bytes

JXL 0.11.1 -e4: 259.400s 83.041s 396,079,448 bytes

----------------------------------------------------

I had a very busy time with HALAC. Now I've given him a break, too. Maybe I can go back to HALIC, which I left unfinished, and do better. That is, more intense and/or faster. Or I can make it work much better in synthetic images. I can also add a mode that is near-lossless. But I don't know if it's worth the time I'm going to spend on it.

Re: A new PNG spec

#385

Post by asadotzler » Wed, Jun 25, 2025, 5:40 PM UTC

AlienRobot wrote: post #180

jillesvangurp wrote: post #111

Earlier quoted context omitted.

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…

>The main use case for PNG is web browsers This is news to me. I'm pretty sure the main use case for PNG is lossless transparent graphics.

Depends on whose use cases you're considering.

There are about 3.6 billion people surfing the web and experiencing PNGs. That use case, consuming PNGs, seems to dwarf the perhaps 100 million (somewhat wild guess) graphic designers, web developers, and photo editing professionals who manipulate images for publishing (in any medium) or archiving.

If, on the other hand, you're considering the use cases envisioned by PNG's creators, or the use cases that interest the people processing or publishing images, yes, these people are focused on format itself and its capabilities.

I suspect this particular use of "use case" isn't terribly clear. Also these two considerations are not incompatible.

Re: A new PNG spec

#386

Post by meindnoch » Wed, Jun 25, 2025, 5:42 PM UTC

pornel wrote: post #310

meindnoch wrote: post #131

Earlier quoted context omitted.

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.

False.

8-bit YCoCg (even when using the reversible YCoCg-R [1] scheme) cannot represent 8-bit RGB losslessly. The chroma channels would need 9 bits of precision to losslessly recover the original 8-bit RGB values.

[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

Re: A new PNG spec

#387

Post by ProgramMax » Wed, Jun 25, 2025, 5:42 PM UTC

rynop wrote: post #378

This is a false claim in the PR: > Many of the programs you use already support the new PNG spec: ... Photoshop, ... Photoshop does NOT support APNGs. The PR calls out APNg recognition as the 2nd bullet point of "What's new?" Am I missing something? Seems like a pretty big mistake. I was excited that an art tool with some marketshare finally supported it.

Phoptoshop supports the HDR part. But you are right, it does not support the APNG part.

Re: A new PNG spec

#388

Post by BobaFloutist » Wed, Jun 25, 2025, 5:44 PM UTC

illiac786 wrote: post #328

BobaFloutist wrote: post #315

Earlier quoted context omitted.

Is there any risk that if I open a JPEG-XL in something that knows what a JPEG is but not what a JPEG-XL is and then save it, it'll get lossy compressed? Backwards compatibility is awesome, but I know that if I save/upload/share/copy a PNG, it shouldn't change without explicit edits, right?

a sw that does not know what jpeg xl is, will not be able to open jxl files. How would it? Not sure what the previous poster meant with “backward compatible” here. jxl is a different format. It can include every information a jpeg includes, which then maybe qualifies as “backward compatible” but it still is a different format.

Ah, got it. I assumed it was a losselessly compressed JPEG with metadata telling modern software not to compress differently but that older software would open as a normal JPEG, but I guess they meant something else with "backward compatible".

Re: A new PNG spec

#389

Post by asadotzler » Wed, Jun 25, 2025, 5:45 PM UTC

whywhywhywhy wrote: post #237

martin_a wrote: post #229

Earlier quoted context omitted.

Adobe Photoshop has support for WebP (through "Save as", not "Export") but I don't think WebP is important.

But it can’t open them

My PS can open them. Maybe update?

Re: A new PNG spec

#390

Post by paisawalla » Wed, Jun 25, 2025, 5:49 PM UTC

joshmarinacci wrote: post #335

A fun trick I do with my web based drawing tools is to save a JSON representation of your document as a comment field inside of a PNG. This way the doc you save is immediately usable as an image but can also be loaded back into the editor. Also means your downloads folder isn’t littered with unintelligible JSON files.

Are you the developer of draw.io?