Add support for PNG 3rd Edition #507
Comments
|
P3D is a separate development. At this moment libpng is a stable implementation of the original PNG specification. The support for P3D is, as I understand it, currently being developed therefore comments on that should go to the appropriate github codebases. Here's the link: |
|
PNG 3rd Edition is in the Candidate Recommendation stage, which means we want people to implement the changes (if they agree with them) to 1.) give us feedback on implementation details (too hard, unrealistic?), and 2.) show support for the changes. This is how we get to the final, finished stage. @digitaltvguy is right to suggest a reference implementation of the PNG spec should have these changes. Other, non-reference implementations have already added the changes and provided feedback. |
|
MacOS has already implemented in their public release. There are other groups that use libpng that are used in broadcast (I.e. Chyron character generators are just one example).
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Chris Blume ***@***.***>
Sent: Thursday, December 21, 2023 10:23:32 PM
To: glennrp/libpng ***@***.***>
Cc: Seeger, Chris (NBCUniversal) ***@***.***>; Mention ***@***.***>
Subject: [EXTERNAL] Re: [glennrp/libpng] Add support for PNG 3rd Edition (Issue #507)
PNG 3rd Edition is in the Candidate Recommendation stage, which means we want people to implement the changes (if they agree with them) to 1.) give us feedback on implementation details (too hard, unrealistic?), and 2.) show support for the changes. This is how we get to the final, finished stage.
@digitaltvguy<https://urldefense.com/v3/__https://github.com/digitaltvguy__;!!PIZeeW5wscynRQ!quHsEkQ-rBzbK9IcbB9Z35eLmwsLB-aIvXFiBdpjtqubtDbl9SiS4twJK4m2gF-Ln8u3v8pxB-jljbXqNuxBO0VKsQ$> is right to suggest a reference implementation of the PNG spec should have these changes. Other, non-reference implementations have already added the changes and provided feedback.
—
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/glennrp/libpng/issues/507*issuecomment-1867186009__;Iw!!PIZeeW5wscynRQ!quHsEkQ-rBzbK9IcbB9Z35eLmwsLB-aIvXFiBdpjtqubtDbl9SiS4twJK4m2gF-Ln8u3v8pxB-jljbXqNuyGGHLigA$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AANIO6BJ36L2455PEUZFEPDYKT4LJAVCNFSM6AAAAABA65WNUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGE4DMMBQHE__;!!PIZeeW5wscynRQ!quHsEkQ-rBzbK9IcbB9Z35eLmwsLB-aIvXFiBdpjtqubtDbl9SiS4twJK4m2gF-Ln8u3v8pxB-jljbXqNuw9dsbtbg$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Indeed. That is what should happen, but until someone implements the changes in libpng and submits a pull request here I don't see that anything can happen in libpng. This is the way it works. Someone has to develop changes and submit them; @ctruta might care to comment if there is some other way. This is what I did for libpng 1.5, libpng 1.6 and libpng 1.7. Believe me it's a lot of work. I can suggest other approaches but it's off topic for this issue which, well, what is the issue @digitaltvguy? |
|
Agreed that someone should make the changes and create a pull request. I might end up creating pull requests with each change in isolation. But I'm hesitant because I've been embarrassingly slow on code updates recently. |
Bear in mind that chunk support for non-approved chunks must use private chunks with appropriate revision tags. For that reason it is likely to be much better to maintain your fork (I'm assuming you are using github) in parallel with libpng 1.6 (i.e. rebasing as required - it's a lot easier with libpng than other projects because libpng changes so infrequently!) In this approach your fork is used for testing/validation until the spec is finalized then is a candidate for inclusion in what would be a major revision (1.8). The alternative approach would be radically new - I can't remember libpng ever having been released with private chunks and clearly it wouldn't be released with unapproved public chunks. What has happened in the past IRC is that new chunk development work has happened on the next, pre-alpha, major version or in manually patched copies of the code; if development work is mixed with maintenance work in the single GIT branch maintenance becomes impossible. Very approximately libpng "major" releases, 1.0, 1.2, 1.4, 1.5, 1.6, have been treated mostly (1.4 is the exception) as what are now called "LTS" releases. Once the first release occurred, 1.x.0, the release became substantially frozen and further development happened in 1.(x+1). When Glenn started using github this was done by creating a new branch which received the patches/(more recently)pull-requests for further development; it was pretty much a dumping ground for development until that development was frozen. @ctruta and other developers who are still around (Greg Roelofs and so on) may care to comment. So far as I can see it is possible at this point to create 1.8 and therefore push 1.6 into LTS state. This would vastly reduce the maintenance requirements. I'm still thinking about this. It's pretty simple but then there is politics and practicality; at present there are no resources to do anything significant in libpng. |
|
Understood. Will do. Thank you. One small change: The chunks I would submit pull requests for would be public. They're already in the spec under Candidate Recommendation with implementations in Chrome, Safari, MacOS, Photoshop, etc. |
You need to use private chunks even in testing. If you don't do this you will end up with data in the real world which has the wrong, malformed, chunks in it; talk to Michael Stokes, or maybe Chris Lilley (if he knows the history in question). PNG was designed in such a way that these errors can be avoided. |
|
I'll try to contact Michael Stokes and will try to read up on what happened. The implementations in those products I mention are for the public chunk listed in the latest spec. (For what it's worth, I believe the Candidate Recommendation phase is beyond the testing phase.) Ironically, we had a problem where a private chunk was in such widespread use that we needed to standardize it, which would normally mean making a public chunk. But there are so many out there, we had to leave it private. |
That's a weakness in the approach but the approach is still solid rock. In general libpng has supported a parallel public and private implementation but I don't think that issue ever had to be extended to a release where the private version was also recognized (I may be wrong - I should be easy to refute if so). Nevertheless, so what? I've always been of the opinion that a tagged private chunk is perfectly fine on its own; it does not need to be a capitalized chunk. This fits with the principles of standardization; standards are not "new" they are merely unambiguous documentation of existing practice. So a standardized "private" chunk is the justification of standardization itself! That's what we are meant to do; document what is already done. We just write things down. |
|
@digitaltvguy please close this. You have identified the three items required for v3 support and these are now in progress; cICP has been picked up and we are waiting for contributors for the other two items. This issue is therefore resolved (by the other three). |
|
The cICP patch hasn't landed yet. Why do you want to close this? That makes no sense. |
|
This issue has been split into three separate issues and that has made this issue redundant; it's covered by the other three. |
|
Can you please list the three separated issues here. I see CICP and MDCV listed. The third seems to be broad (full support of 3rd Edition. Although, CICP and MDCV will be an extremely helpful first step for cinema and broadcast production. |
|
With separate issues for the individual pieces, this issue is a meta-issue. |
|
@ctruta I am unable to add labels to those issues. I was thinking a simple "png-3" but am open to whatever. |
@ProgramMax @jbowler I sent you an invite to join pnggroup. I should have done it long ago. Now, on to the real "PNG Group", which is still (formally, by self-definition) the members of our mailing lists. Over there, we've been partying like it's the nineties, and the very few of us who still do, will need to (formally, by self-redefinition) move over here, where the cool kids hang out nowadays. I'll think about it, and then I'll do something about it, hopefully tomorrow. |
It is critical to adding signaling support for explicit video image formats for HDR like PQ, HLG and even SDR BT.709.
I'm happy to discuss
The text was updated successfully, but these errors were encountered: