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

61–70 of 622 posts

Re: A new PNG spec

#61

Post by danielheath »

mrheosuper wrote: post #56
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.

the parent said "changing the compression algorithm will break backwards compatibility", which i assume is something works now won't work in the future. The usb-c spec is intentionally trying to avoid that.

Today, I can save a PNG file off a random website and then open it.

If PNG gets extended, it's entirely plausible that someone will view a PNG in their browser, save it, and then not be able to open the file they just saved.

There are those who claim "backwards compatibility" doesn't cover "how you use it" - but roughly none of the people who now have to deal with broken software care about such semantic arguments. It used to work, and now it doesn't.

Re: A new PNG spec

#62

Post by fragmede »

techpression wrote: post #33
mrheosuper wrote: post #26

Earlier quoted context omitted.

Does usb-c spec break backward compatibility ?, a 2018 macbook work perfectly fine with 2025 usb c charger

I don’t know if it’s the spec or just a plethora of vendors that ignores it, but I have many things with a USB-C port that requires USB-A as source. USB-C to A to C works, yay dongles, but not just C to C. So maybe it’s not really breaking backwards compatibility, just a weird mix of a port and the communication being separate standards.

it's vendors just changing the physical port but not updating the electronics. specifically, a 5.1kΩ pull-up resistors on the CC1 and/or CC pins is needed on the host (was usb-a) side in order for the c to c cable to work.

Re: A new PNG spec

#63

Post by johnisgood »

jandrese wrote: post #19
qwertox wrote: post #10

> Officially supports Exif data Probably the best news here. While you already can write custom data into a header, having Exif is good. BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.

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.

And I strip Exif data, too, intentionally, for similar reasons.

Re: A new PNG spec

#65

Post by voidUpdate »

yoz-y wrote: post #47
mrheosuper wrote: post #41

Earlier quoted context omitted.

That is not backward compatible problem. If a cable that does 100w charging when using pd2.0, but only 60w when using with pd3.1 device, then i would agree with you.

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.

That's not just an issue with usb-c. normal usb a and b cables can have data or no data depending on how stingy the company wants to be, and you can't know until you test it

Re: A new PNG spec

#66

Post by bayindirh »

koito17 wrote: post #24
Lerc wrote: post #15

Earlier quoted context omitted.

It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.

> Having an extensible format and electing never to extend it seems pointless. This proves OP analogy regarding USB-C. Having PNG as some generic container for lossless bitmap compression means fragmentation in libraries, hardware support, etc. The reason being that if the container starts to support too many formats, implementations will start restricting to only the subsets the implementers care about. For instance…

JPEG is no different. Only the decoder is specified. As long as the decoder decodes what you give it to the image you wanted to see, you can implement anything. This is how imgoptim/squash/aerate/dietJPG works. By (ab)using this flexibility.

Same is also true for the most advanced codecs. MPEG-* family and MP3 comes to my mind.

Nothing stops PNG from defining a "set of decoders", and let implementers loose on that spec to develop encoders which generate valid files. Then developers can go to town with their creativity.

Re: A new PNG spec

#67

Post by johnisgood »

danielheath wrote: post #61
mrheosuper wrote: post #56

Earlier quoted context omitted.

the parent said "changing the compression algorithm will break backwards compatibility", which i assume is something works now won't work in the future. The usb-c spec is intentionally trying to avoid that.

Today, I can save a PNG file off a random website and then open it. If PNG gets extended, it's entirely plausible that someone will view a PNG in their browser, save it, and then not be able to open the file they just saved. There are those who claim "backwards compatibility" doesn't cover "how you use it" - but roughly none of the people who now have to deal with broken software care about such semantic arguments. I…

This is what I fear, too.

Do they mention which C libraries use this spec?

Re: A new PNG spec

#69

Post by jajko »

pvorb wrote: post #46
Lerc wrote: post #15

Earlier quoted context omitted.

It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress. The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.

Extending the format just because you can – and breaking backwards compatibility along the way – is even more pointless. If you've created an extensible file format, but you never need to extend it, you've done everything right, I'd say.

What about an extensible format that would have as part of header an algorithm (in some recognized DSL) of how to decompress it (or any other step required for image manipulation)? I know its not so much about PNG but some future format.

That's what I would call really extensible, but then there may be no limits and hacking/viruses could have easily a field day.

Re: A new PNG spec

#70

Post by Joel_Mckay »

morjom wrote: post #52
Joel_Mckay wrote: post #25

DaVinci Resolve also supports OpenEXR format with the added magic of LUT. PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases. Even after spending a few grand on seats for a project, one still gets arrogant 3D clown-ware vendors telling people how they should run their pipeline with PNG hot garbage as input. People should choose EXR…

What are some "consistent color standards" you'd recommend? Honest question.

Like all complex questions, the answer is it depends on the target project and or Display.

A very basic rec.709 workflow tutorial:

https://www.youtube.com/watch?v=lf8COHAgHJs

The Andreas Dürr LUT pack:

https://www.youtube.com/watch?v=dDKK54CeXgM

https://cinematiccookie.gumroad.com/l/bseftb?layout=profile

The calibration workflows also depend heavily on what is being rendered, source application(s), and the desired content look. There were some common free packs on github for popular programs at one time. Should still be around someplace... good luck. =3

Post reply on HN