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

401–410 of 622 posts

Re: A new PNG spec

#401

Post by wongarsu »

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

> advanced compression (finite-state entropy, like ZStandard) I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will nev…

PNG's basic idea is to store the difference between the current pixel and the pixel above it, left of it or to the top-left (chosen once per row), then apply standard deflate compression to that. The first step basically turns gradients into repeating patterns of small numbers, which compress great. You can get decent improvements by just switching deflate for zstd

Re: A new PNG spec

#402

Post by meindnoch »

Retr0id wrote: post #227
meindnoch wrote: post #123

Parallel compression/decompression is already possible via Z_SYNC_FLUSH.

Parallel de compression of Z_SYNC_FLUSH'd data is not possible without additional metadata to tell you where the sync points are.

True. Although this can be mitigated in a backwards compatible manner, by adding a new PNG chunk that points to the locations of the sync points.

Re: A new PNG spec

#403

Post by armada651 »

Aissen wrote: post #120
armada651 wrote: post #81

Earlier quoted context omitted.

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

You're correct and I was considering adding a footnote that if you use indexed colors like a GIF then PNG can beat GIF due to better compression algorithms. But when most people think of APNG they think of lossless compression rather than lossy compression.

Re: A new PNG spec

#404

Post by meindnoch »

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

Could you expand on this? It sounds a bit preposterous to save a text, as json, inside an image - and then expect it to be immediately usable… as an image?

Check what draw.io does when you download a PNG.

Re: A new PNG spec

#405

Post by Retr0id »

meindnoch wrote: post #402
Retr0id wrote: post #227

Earlier quoted context omitted.

Parallel de compression of Z_SYNC_FLUSH'd data is not possible without additional metadata to tell you where the sync points are.

True. Although this can be mitigated in a backwards compatible manner, by adding a new PNG chunk that points to the locations of the sync points.

Yes, such a chunk is being considered for introduction in future PNG revisions.

Re: A new PNG spec

#406

Post by meindnoch »

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

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.

Only if the image width/height is a multiple of 8. See: the manpage of jpegtran, especially the -p flag.

Re: A new PNG spec

#407

Post by shiryel »

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.

That is also how Krita stores brushes. Unfortunately, that can cause some unexpected issues when there's too much data [1][2].

[1] - https://github.com/Draneria/Metallics-by-Draneria_Krita-Brus...

[2] - https://krita-artists.org/t/memileo-impasto-brushes/92952/11...

Re: A new PNG spec

#410

Post by KetoManx64 »

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

A fun trick, but I wouldn't want to explain to users why their things are saved as a .png, not why their things is lost after they opened and saved the PNG in Paint.

If a user is using paint to edit their photos, they're 100% not going to be interested in having the source document to play around with.
Post reply on HN