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

431–440 of 622 posts

Re: A new PNG spec

#431

Post by ksec »

illiac786 wrote: post #312
ksec wrote: post #273

Earlier quoted context omitted.

I hope I am very wrong but this isn't given. In the past reference encoder and decoder do not concern about speed and resources, but last 10 years have shown most reference encoder and decoder has already put considerable effort into speed optimisation. And it seems people are already looking to hardware JPEG XL implementation. ( I hope and guess this is for Lossless only )

I would agree we will see less improvements that when comparing modern jpeg implementation and the reference one. When it comes to hardware encoding/decoding, I am not following your point I think. The fact that some are already looking at hardware implementation for JPEG XL means that….? I just know JPEG hardware acceleration is quite common, hence I am trying to understand how that makes JPEG XL different/better/wo…

In terms of PC usage, JPEG, or most image codec decoding are done via software and not hardware. AFAIK even AVIF decoding is done via software on browser.

Hardware acceleration for lossless makes more sense for JPEG XL because it is currently very slow. As the author of HALIC posted some results below, JPEG XL is about 20 - 50x slower while requiring lots of memory after memory optimisation. And about 10 - 20 times slower compared to other lossless codec. JPEG XL is already used by Camera and stored as DNG, but encoding resources is limiting its reach. Hence hardware encoder would be great.

For lossy JPEG XL, not so much. Just like video codec, hardware encoder tends to focus on speed and it takes multiple iteration or 5 - 10 years before it catches up on quality. JPEG XL is relatively new with so many tools and usage optimisation which even current software encoder is far from reaching the codec's potential. And I dont want crappy quality JPEG XL hardware encoder, hence I much prefer an upgradeable software encoder for JPEG XL lossy and hardware encoder for JPEG XL Lossless.

Re: A new PNG spec

#432

Post by ksec »

poly2it wrote: post #418
thesz wrote: post #297

Earlier quoted context omitted.

HALIC discussion page [1] says otherwise. [1] https://encode.su/threads/4025-HALIC-(High-Availability-Loss... It looks like LEA 0.5 is the champion. And HALIC is not even close to ten in this [2] lossless image compression benchmark. [2] https://github.com/WangXuan95/Image-Compression-Benchmark

It looks like HALIC offers very impressive decode speeds within its compression range.

And not just decoding speed but also encoding speed with difference of an order of magnitude. Some new results further down in the comments in this thread. Had it not been verified I would have thought it was a scam.

Re: A new PNG spec

#433

Post by dveditz_ »

illiac786 wrote: post #329
sdenton4 wrote: post #320

Earlier quoted context omitted.

Looking at TFA, it's placing in the spec a few things that are already widely stacked onto the format (such as animation). This is a very sensible update, and backwards compatible with existing PNG.

Not sure expanding PNG capabilities is sensible, looking at the overall landscape of image formats.

The capabilities are already expanded in most common implementations. This update is largely blessing those features as officially "standard".

Re: A new PNG spec

#434

Post by dveditz_ »

jerf wrote: post #396
albert_e wrote: post #29

Earlier quoted context omitted.

Oh TIL - Thanks! This could possibly be used to build full fledged games like pong and breakout :)

SVG also supports Javascript, which will probably be a lot more useful for games.

It supports JavaScript when used as a document, but when used as an "image" by a browser (IMG tag, CSS features) JavaScript and the loading of external resources are disabled.

Re: A new PNG spec

#435

Post by ProgramMax »

Joel_Mckay wrote: post #428
ProgramMax wrote: post #412

Earlier quoted context omitted.

0xFF is 8-bit. PNG supports up to 16-bit. It always has. Plus, PNG now supports full HDR so the fireball won't look washed out. I think your experience is with some tool that made bad PNGs. That is a problem with the tool, not the format.

EXR stores the color-space information differently, and you missed the point. Have a look at a tutorial that dives into the basic details, and consider learning something: https://www.youtube.com/watch?v=pLt1230dtYE https://www.youtube.com/watch?v=mb0b83MML78 https://www.youtube.com/watch?v=egtnkhuUe_E PNG has its use-cases, and some people do expect that baked color-space garbage look given it dominates a lot of low…

I'm trying to follow your point. But...there are problems with your claims. Yes, EXR stores color-space differently than PNG. Because EXR doesn't store color space at all.

In the first video, the person loads the image and manually chooses a gamma transfer function with 2.2. If that was then saved, it would produce the washed-out fireball you mentioned.

In the second video, the person loads the image and manually chooses rec.709, which is also gamma tf and also produces washed-out fireball. In fact, the EXR image he loads literally has a bright fireball and you see it get washed out.

If you want to make claims about EXR being better than PNG, you need to say why storing the values as floating point is better than integer. But the blown-out fireball example is just incorrect. As evidence, I'll point to HDR. ANYTHING you see in an HDR movie is now 100% losslessly reproducible in a PNG.

Re: A new PNG spec

#436

Post by IvanK_net »

giancarlostoro wrote: post #422
IvanK_net wrote: post #419

Earlier quoted context omitted.

Macromedia did this when saving Fireworks files into PNG. Also, Adobe saves AI files into a PDF (every AI file is a PDF file), and Photoshop can save PSD files into TIFF files (people wonder why these TIFFs have several layers in Photoshop, but just one layer in all other software).

> Macromedia did this when saving Fireworks files into PNG. I forgot about this.. Fireworks was my favorite image editor, I don't know that I've ever found one I love as much as I loved Fireworks. I'm not a graphics guy, but Fireworks was just fantastic.

BTW. I am the author of https://www.photopea.com , which is the only software that can open Fireworks files today :D If you have any files, try to open theim (it runs instantly in your browser).

https://community.adobe.com/t5/fireworks-discussions/open-fi...

Re: A new PNG spec

#437

Post by kevin_thibedeau »

mystifyingpoi wrote: post #58
yoz-y wrote: post #47

Earlier quoted context omitted.

The problem is not backward compatibility but labeling. A USB-C cable looks universal but isn’t. Some of them just charge, some do data, some do PD, some give you access to high speed. But there is no way to know. I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.

Cable labeling could fix 99% of the issues with USB-C compat. The solution should never be blaming consumer for buying the wrong cable. Crappy two-wire charge-only cables are perfectly fine for something like a night desk lamp. Keep the poor cables, they are okay, just tell me if that's the case.

Two wire cables are not in the specification, just like A-to-A cables aren't. The whole charging above 100mA with resistor hacks wasn't in the standard either until they had to grandfather it in. The implementers forum isn't responsible for non-members breaking their spec.

Re: A new PNG spec

#438

Post by Dylan16807 »

bmn__ wrote: post #339
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.

> just https://caniuse.com/jpegxl No one can afford to "just". Five years later and it's only one browser! Crazy. Browser vendors must deliver, only then it's okay to admonish an end user or Web developer to adopt the format.

Adopt it anyway. Add a decoder. Don't let google bully you out of such a good format.

Re: A new PNG spec

#439

Post by Joel_Mckay »

ProgramMax wrote: post #435
Joel_Mckay wrote: post #428

Earlier quoted context omitted.

EXR stores the color-space information differently, and you missed the point. Have a look at a tutorial that dives into the basic details, and consider learning something: https://www.youtube.com/watch?v=pLt1230dtYE https://www.youtube.com/watch?v=mb0b83MML78 https://www.youtube.com/watch?v=egtnkhuUe_E PNG has its use-cases, and some people do expect that baked color-space garbage look given it dominates a lot of low…

I'm trying to follow your point. But...there are problems with your claims. Yes, EXR stores color-space differently than PNG. Because EXR doesn't store color space at all. In the first video, the person loads the image and manually chooses a gamma transfer function with 2.2. If that was then saved, it would produce the washed-out fireball you mentioned. In the second video, the person loads the image and manually cho…

[flagged]

Re: A new PNG spec

#440

Post by fwip »

ProgramMax wrote: post #427

Author here. Hello everyone! Feel free to ask me anything. I'll go ahead and dispel some doubts I already see here: - It isn't really a "new format". It's an update to the existing format. - It is very backwards compatible. -- Old programs will load new PNGs to the best of their capability. A user will still know "that is a picture of a red apple". There also seems to be some confusion about how PNGs work internally.…

Do you have any examples on hand of PNGs that use the new features of the spec? It would be cool to see a little demo page with animated or HDR images, especially to download to test if our programs support them yet.
Post reply on HN