- From: Seeger, Chris (NBCUniversal) <Chris.Seeger@nbcuni.com>
- Date: Sun, 5 Jan 2025 01:41:12 +0000
- To: "jbowler@acm.org" <jbowler@acm.org>, "Portable Network Graphics (PNG) Working Group" <public-png@w3.org>
- Message-ID: <BL0PR14MB37950B94707738A7C5B38A3EE6172@BL0PR14MB3795.namprd14.prod.outlook.com>
Thanks for doing the work John, It’s very much appreciated. From: John Bowler <john.cunningham.bowler@gmail.com> Date: Saturday, January 4, 2025 at 7:18 PM To: Portable Network Graphics (PNG) Working Group <public-png@w3.org> Cc: Seeger, Chris (NBCUniversal) <Chris.Seeger@nbcuni.com> Subject: Re: [EXTERNAL] Re: [PNG] Meeting topics - Jan 6, 2025 On Sat, Jan 4, 2025 at 3:58 PM Seeger, Chris (NBCUniversal) <Chris.Seeger@nbcuni.com<mailto:Chris.Seeger@nbcuni.com>> wrote: I certainly second what Chris says. I've cross posted my previous response on the #issue I previously referenced. For myself and perhaps others not in the industry mDCV and, also, cLLI are essential additions to the PNG standard to allow us to encode original data without data loss. I concur with Chris that the information has limited use in a content creation pipeline and, indeed, may, because these chunks are ancillary (like cICP etc), be simply discarded in a completely conformant PNG decoder. I.e. it's just a postit someone stuck on your monitor. All ancillary chunks are. I cannot dispute Chris's statements with regard to the broadcast industry; cICP is the tool they have given me and that is the tool I have. So my only issue, as an individual, is that I've supplied code that does, in fact, implement mDCV and cLLI in an, I believe, completely conformant and bug free way. Therefore I would like it to be included too. Not because I am great or good and not because I want it (even though I do) but because I believe a lot of the PNG community really do need it. Anyway, it's free.
Received on Sunday, 5 January 2025 01:41:55 UTC