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

501–510 of 622 posts

Re: A new PNG spec

#501

Post by account42 »

derefr wrote: post #446
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.…

So, I'm a big fan of metaformats with generalized tooling support. Think of e.g. Office Open XML or ePub — you don't need "an OOXML parser" / "an ePub parser" to parse these; they're both just zipped XML, so you just need a zipfile library and libxml. For the lifetime of PNG so far, a PNG file has almost, but just barely not , been a valid Interchange File Format (IFF) file. IFF is a great (simple to understand, simp…

We really shouldn't be making new standards with big endian byte order.

It's also questionable how much you actually benefit from common container formats like this since you need to know the application specific format contained anyway in order to do anything useful with it. It also causes problems where "smart" programs treat files in ways that make no sense, e.g. by offering to extract a .docx file just because it looks like a .zip

Re: A new PNG spec

#502

Post by account42 »

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.

It can also become a security issue when users inadvertendly share layers/history/whatever that isn't visible anymore in the final image but still in the editable part.

Re: A new PNG spec

#503

Post by account42 »

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.

Last I checked cwebp does not preserve PNG color space information properly so the result isn't actually visually lossless.

Re: A new PNG spec

#504

Post by account42 »

illiac786 wrote: post #263
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

> If there are any problems it is its encoding and decoding speed and resources. And this will improve over time, like jpg encoders and decoders did.

Or it won't like JPEG 2000 encoders didn't.

Re: A new PNG spec

#505

Post by account42 »

HakanAbbas wrote: post #384
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 alo…

> In other words, the fastest or the best compression maker alone does not matter.

Strictly true, but e.g. for archival or content delivered to many users compression speed and memory needed for compression is an afterthought compared to compressed size.

Re: A new PNG spec

#506

Post by account42 »

DidYaWipe wrote: post #460
ralferoo wrote: post #161

Earlier quoted context omitted.

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.

Indeed. Whenever I'm using an image browser/manager application that supports rotating images, I wonder if it's doing JPEG rotation properly (as you describe) or just flipping the dumb flag.

Or lossy re-encoding.

Re: A new PNG spec

#507

Post by account42 »

Someone wrote: post #333
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.

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

Sensors are not read out as JPEG but into intermediate memory. The encoding step can then deal with the needed rotation.

RAW images aren't JPEGs so not relevant to the discussion.

Re: A new PNG spec

#508

Post by account42 »

kllrnohj wrote: post #305
airstrike wrote: post #240

Earlier quoted context omitted.

How is rotation during rendering free?

For anything GPU-rendered, applying a rotation matrix to a texture sample and/or frame-buffer write is trivially cheap (see also why Vulkan prerotation exists on Android). Even ignoring GPU-rendering, you always are doing a copy as part of rendering and often have some sort of matrix operation anyway at which point concatenating a rotation matrix often doesn't change much of anything.

The cost is paid in different memory access patterns which may or may not be mitigated by the GPU scheduler. It's an insignificant cost either way though, both for the encoder and the renderer. Also depending on the pixel order in sensor, file or frame buffer "rotated" might actually be the native way and the default is where things get flipped around from source to destination.

Re: A new PNG spec

#509

Post by account42 »

mavhc wrote: post #108
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.

Because your non-smartphone camera doesn't have enough ram/speed to do that I assume (when in burst mode) If a smartphone camera is doing it, then bad camera app!

Burst mode in cameras means the sensor is readout is buffered in RAM while the encoding and writing to persistent storage catches up. Rotating the buffer would be part of the latter and not affect burst speed - and is an insignificant cost anyway.

Re: A new PNG spec

#510

Post by account42 »

sunaookami wrote: post #485
jandrese wrote: post #19

Earlier quoted context omitted.

Yes, but websites frequently strip all or almost all Exif data from uploaded images because some fields are used by stalkers to track people down to their real address.

That reminds me when I first uploaded a picture to some forum and it showed my full home address together with a map as a "feature"

It is a feature because now you are aware of what you are sharing and can potentially delete it before too many others see it.
Post reply on HN