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

361–370 of 622 posts

Re: A new PNG spec

#361

Post by chown »

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?

Save text as JSON as comments but the file itself is a PNG so that you can use it as an image (like previewing it) as they would ignore the comments. However, the OP’s editor can load the file back, parse the comments, and get the original data and continue to edit. Just one file to maintain. Quite clever actually.

Re: A new PNG spec

#362

Post by joquarky »

gmueckl wrote: post #348
razorfen wrote: post #340

Can anyone explain how they maintain backwards compatibility on formats like this when adding features? I assume there are byte ranges managed in the format, but with things like compression, wouldn’t compressed images be unrenderable on clients that don’t support it? I suppose it would behoove servers to serve based on what the client would support.

In mynunderstanding, the actual image data encoding isn't altered in this update. It only introduces an extended color space definition for the encoded data. PNG is a highly structured file format internally. It borrows design ideas from formats like EA's Interchange File Format in that it contains lists of chunks with fixed headers encoding chunk type amd length. Decoders are expected to parse them and ignore chunk…

The Amiga was quite a platform. Glad to know that it had some long term influence.

Re: A new PNG spec

#363

Post by colejohnson66 »

liuliu wrote: post #349
illiac786 wrote: post #328

Earlier quoted context omitted.

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.

JPEG XL has the mode that in layman's word, allow bit-by-bit round-trip with JPEG. Original JPEG -> JPEG XL -> Recreated JPEG. Sha256(Original JPEG) == Sha256(Recreated JPEG). That's what people meant by "backward compatible".

That’s not “backwards compatible”, but “round tripable” or “lossless reencode”

Re: A new PNG spec

#364

Post by jandrese »

bspammer wrote: post #112
johnisgood wrote: post #63

Earlier quoted context omitted.

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.

If you are uploading it to a website you are sharing it. Even if the image is supposedly "private" you have to assume it will be leaked at some point. Remember, the cloud is just someone else's computer, and they can do what they want with their computer. They may also not be entirely competent at their job.

Re: A new PNG spec

#365

Post by cormorant »

LegionMammal978 wrote: post #4

Reading the linked blog post on the new cICP chunk type [0], it looks like the "proper HDR support" isn't something that you couldn't already do with an embedded ICC profile, but instead a much-abbreviated form of the colorspace information suitable for small image files. [0] https://svgees.us/blog/cICP.html

"common but not representable RGB spaces like Adobe 1998 RGB or ProPhoto RGB cannot use CICP and have to be identified with ICC profiles instead."

cICP is 16 bytes for identifying one out of a "list of known spaces" but they chose not to include a couple of the most common ones. Off to a great start...

I wonder if it's some kind of legal issue with Adobe. That would also explain why EXIF / DCF refer to Adobe RGB only by the euphemism "optional color space" or "option file". [1]

[1] https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...

Re: A new PNG spec

#366

Post by woodrowbarlow »

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?

this is useful for code that renders images (e.g. data-visualization tools). the image is the primary artifact of interest, but maybe it was generated from data represented in JSON format. by embedding the source data (invisibly) in the image, you can extract it later to modify and re-generate.

Re: A new PNG spec

#367

Post by joquarky »

pornel wrote: post #314
bigfishrunning wrote: post #299

Earlier quoted context omitted.

why not? that's up to the program displaying the animation, not the animation itself -- i'm sure a pausable gif or apng display program is possible

It's absolutely possible. Browsers even routinely pause playback when images aren't visible on screen. They just don't have a proper UI and JS APIs exposed, and there's nothing stopping them from adding that. IMO browsers are just stuck with tech debt, and maintainin a no-longer-relevant distinction between "animations" and "videos". Every supported codec should work wherever GIF/APNG work and vice versa. It's not ev…

I wish browsers still paused all animations when the user hits the Esc key. It's hard to read when there are distracting animations all over most pages.

Re: A new PNG spec

#368

Post by ChrisMarshallNY »

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

Looks like it's basically reaffirming what a lot of folks have been doing, unofficially.

For myself, I use PNG only for computer-generated still images. I tend to use good ol' JPEG for photos.

Re: A new PNG spec

#370

Post by dtech »

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.
Post reply on HN