Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for PNG 3rd Edition #507

Closed
digitaltvguy opened this issue Dec 21, 2023 · 18 comments
Closed

Add support for PNG 3rd Edition #507

digitaltvguy opened this issue Dec 21, 2023 · 18 comments

Comments

@digitaltvguy
Copy link

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

@jbowler
Copy link
Contributor

jbowler commented Dec 22, 2023

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:

https://github.com/w3c/PNG-spec/issues/new

@ProgramMax
Copy link
Contributor

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.

@digitaltvguy
Copy link
Author

digitaltvguy commented Dec 22, 2023 via email

@jbowler
Copy link
Contributor

jbowler commented Dec 22, 2023

PNG 3rd Edition is in the Candidate Recommendation stage, which means we want people to implement the changes

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?

@ProgramMax
Copy link
Contributor

Agreed that someone should make the changes and create a pull request.
But we can also have an issue open to signal to those people what contributions they might want to make. (The issue doesn't force the maintainers to be the ones who make the changes.)

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.

@jbowler
Copy link
Contributor

jbowler commented Dec 24, 2023

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.

@ProgramMax
Copy link
Contributor

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.

@jbowler
Copy link
Contributor

jbowler commented Dec 24, 2023

The chunks I would submit pull requests for would be public. They're already in the spec under Candidate Recommendation

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.

@ProgramMax
Copy link
Contributor

I'll try to contact Michael Stokes and will try to read up on what happened.
I am in direct contact with Chris Lilley. He and I have been working hard on that latest PNG spec edition.

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.

@jbowler
Copy link
Contributor

jbowler commented Dec 24, 2023

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.

@jbowler
Copy link
Contributor

jbowler commented Sep 12, 2024

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

@ProgramMax
Copy link
Contributor

The cICP patch hasn't landed yet.
The other two parts don't even have a pull requests.
The issue is clearly not yet resolved.

Why do you want to close this? That makes no sense.

@jbowler
Copy link
Contributor

jbowler commented Sep 14, 2024

This issue has been split into three separate issues and that has made this issue redundant; it's covered by the other three.

@digitaltvguy
Copy link
Author

digitaltvguy commented Sep 15, 2024

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.

@jbowler
Copy link
Contributor

jbowler commented Sep 15, 2024

Identified issues are:

#508 [cICP priority 1: encoding ('unsafe-to-copy') chunk]
#509 [mDCv priority 2: metadata ('safe-to-copy') chunk]
#510 [cLLI priority 3: metadata ('safe-to-copy') chunk]
#267 [APNG support: acT, fcTL, fdAT ('safe-to-copy', privately defined) chunks.]

@ProgramMax
Copy link
Contributor

With separate issues for the individual pieces, this issue is a meta-issue.
We can also track meta-issues via GitHub's labels, projects, and milestones.
I prefer one of those options. So with individual issues, I agree with @jbowler that we can close this, if we're all cool with using labels for example.

@ProgramMax
Copy link
Contributor

@ctruta I am unable to add labels to those issues. I was thinking a simple "png-3" but am open to whatever.
Would you mind either creating & applying a label or granting me permission to do it? Thanks

@ctruta
Copy link
Member

ctruta commented Sep 30, 2024

@ctruta I am unable to add labels to those issues. I was thinking a simple "png-3" but am open to whatever. Would you mind either creating & applying a label or granting me permission to do it? Thanks

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants