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

331–340 of 622 posts

Re: A new PNG spec

#331

Post by lazide »

cptcobalt wrote: post #321

It seems like this new PNG spec just cements what exists already, great! The best codecs are the ones that work on everything. PNG and JPEG work everywhere, reliably. Try opening a HEIC or AV1 or something on a machine that doesn't natively support it down to the OS-level, and you're in for a bad time. This stuff needs to work everywhere—in every app, in the OS shell for quick-looking at files, in APIs, on Linux, etc…

This new spec will make PNG even worse than HEIC or AV1 - you won’t know what codec is actually inside the PNG until you open it.

Re: A new PNG spec

#332

Post by ecshafer »

cptcobalt wrote: post #321

It seems like this new PNG spec just cements what exists already, great! The best codecs are the ones that work on everything. PNG and JPEG work everywhere, reliably. Try opening a HEIC or AV1 or something on a machine that doesn't natively support it down to the OS-level, and you're in for a bad time. This stuff needs to work everywhere—in every app, in the OS shell for quick-looking at files, in APIs, on Linux, etc…

I work with a LOT of images in a lot of image formats, many including extremely niche formats used in specific fields. There is a massive challenge in really supporting all of these, especially when you get down to the fact that some specs are a little looser than others. Even libraries can be very rough, since sure it says on the tin it supports JPG and TIF and HEIC... but does it support a 30GB Jpeg? Does it support all possibly meta data in the file?

Re: A new PNG spec

#333

Post by Someone »

DidYaWipe wrote: post #85
Aardwolf wrote: post #18

Earlier quoted context omitted.

Exif can also cause confusion for how to render the image: should its rotation be applied or not? Old decoders and new decoders now could render an image with exif rotation differently since it's an optional chunk that can be ignored, and even for new decoders, the spec lists no decoder recommendations for how to use the exif rotation It does say "It is recommended that unless a decoder has independent knowledge of t…

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.

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

The hardware likely is optimized for the common case, so I would think that can be a lot slower. It wouldn’t surprise me, for example, if there are image sensors out there that can only be read out in top to bottom, left to right order.

Also, with RAW images and sensors that aren’t rectangular grids, I think that would complicate RAW images parsing. Code for that could have to support up to four different formats, depending on how the sensor is designed,

Re: A new PNG spec

#334

Post by LocalH »

npteljes wrote: post #294
LocalH wrote: post #253

Earlier quoted context omitted.

I've said "jif" for almost 40 years, and I'm not stopping anytime soon. Hard-g is wrong , and those who use it are showing they have zero respect for others when they don't have to. It's the tech equivalent to the shopping cart problem. What do you do when there is no incentive one way or the other? Do you do the right thing, or do you disrespect others?

As much as I hate jif , thinking about it, "GPU" works the same - we say gee-pee-you and not gh-pee-you . Garbage Collection is also gee-cee . So it's only logical that jif is the correct one - even if it's not the widely accepted one. Wrt/ communication, aside from personal preference, one can either respect the creator, or the audience. If I stand in front of 10 colleagues, 10 out of them would not understand jif ,…

The whole debate seems to be a modern phenomenon to me - from my anecdotal experience back in the day, it was never questioned by computer enthusiasts that it was pronounced "jif".

Re: A new PNG spec

#335

Post by joshmarinacci »

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.

Re: A new PNG spec

#336

Post by xdennis »

pwdisswordfishz wrote: post #276
LocalH wrote: post #253

Earlier quoted context omitted.

I've said "jif" for almost 40 years, and I'm not stopping anytime soon. Hard-g is wrong , and those who use it are showing they have zero respect for others when they don't have to. It's the tech equivalent to the shopping cart problem. What do you do when there is no incentive one way or the other? Do you do the right thing, or do you disrespect others?

Linguistic prescriptivism is wrong , and people who promote it are showing they have zero respect for others when they don't have to.

Linguistic prescriptivism has nothing to do with it.

English has both pronunciations for "gi" based on origin. Giraffe, giant, ginger, etc from Latin; gift, give, (and presumably others) from Germanic roots.

Using the preferred one is just a matter of politeness.

Also, it's quite ironic to prescribe "linguistic prescriptivism" as wrong.

Re: A new PNG spec

#337

Post by eviks »

tonyedgecombe wrote: post #186
eviks wrote: post #121

Earlier quoted context omitted.

> [not] Officially supports Exif data How can you call this basic fail a success?

Exif data might be important to you but it clearly hasn't stopped the adoption of png.

Yes, plenty of tech garbage floats at the top, the question is why would you argue that lack of basic fixes over decades is not stagnation, but something positive

Re: A new PNG spec

#338

Post by Dwedit »

rurban wrote: post #177
Dwedit wrote: post #92

If you wanted better compression, it's called Lossless WEBP. Lossless WEBP is such a nice codec. Compared with Lossless JXL, it decompresses many times more quickly, and while JXL usually produces a smaller file, it doesn't always. Lossless AVIF is not competitive. However, lossless WEBP does not support indexed color images. If you need palettes, you're stuck with PNG for now.

And the JXL api is a nightmare, compared to WEBP.

Yeah, the whole "subscribe to events then check a status result" thing is pretty bad. This is compounded by "Box" behaving differently than everything else. When I made JxlSharp (C# JXL library wrapper), I had to add a workaround in there to force Box to behave like all the other event subscriptions.

And buffer sizes aren't handled in a good way. You have to provide pre-allocated memory, guessing how big it is supposed to be. Then you get a "not big enough" error. This is a guessing game, not a good design. You're forced to overshoot, then shrink the buffer afterwards.

---

In different APIs, there tends to be a function you call to get the required buffer size. For example, many Win32 API functions make you call them with a buffer size of 0, then you get the actual required size back. Another possibility is having the library allocate the memory, and return the allocated buffer to you. Since cross-module memory management is hairy (different `malloc` implementations can't interoperate), some APIs let you provide the `malloc`, `realloc`, and `free` functions.

Re: A new PNG spec

#339

Post by bmn__ »

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.

Re: A new PNG spec

#340

Post by razorfen »

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