- From: Seeger, Chris (NBCUniversal) <Chris.Seeger@nbcuni.com>
- Date: Fri, 28 Feb 2025 02:14:20 +0000
- To: "Chris Blume (ProgramMax)" <programmax@gmail.com>, Fares Alhassen <falhassen@google.com>
- CC: "jbowler@acm.org" <jbowler@acm.org>, "public-png@w3.org" <public-png@w3.org>
- Message-ID: <BL0PR14MB3795FCEF7A34927BDFC399D7E6CC2@BL0PR14MB3795.namprd14.prod.outlook.com>
What’s the loopback to BT.2408 for? Best, Chris Get Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Chris Blume (ProgramMax) <programmax@gmail.com> Sent: Thursday, February 27, 2025 8:25:42 PM To: Fares Alhassen <falhassen@google.com> Cc: jbowler@acm.org <jbowler@acm.org>; public-png@w3.org <public-png@w3.org> Subject: [EXTERNAL] Re: [PNG] Cancel upcoming meeting? so sleep is cancelled RIP sleep. It isn't a break but it is an incompatible new version Agreed. I expect that to be significantly more scrutinized, questioned, and tested. I guess I should file it under "maybe". ISO 22028-5 paywalled Oh. That's a problem. We need to loop back on if ITU-R BT.2408 is effectively the same (and not paywalled). cHRM chunk fix Oh! Right! I forgot about that one. Thank you. I think that is likely to get in. I tried playing devil's advocate and pretty much everyone I spoke to wanted it. Devil's advocate was the only pushback. a cracker can use it to defeat a decoder which uses the restart marker I didn't understand this. Do you mean "There is a restart marker at bit index 200" but there isn't, so the parallel and serial decodes are different? Much much better to encode in blocks I agree. Pretty much every modern image compression I know operates on blocks. I think we'll have a very hard time getting that into PNG though. That would be a pretty radical change. ISO <-> W3C liaison vote Heyyyy nice! ISO 21496-1 paywalled Oh dear. I'll leave it to the liaisons to discuss this. On Thu, Feb 27, 2025 at 8:10 PM Fares Alhassen <falhassen@google.com<mailto:falhassen@google.com>> wrote: Dear all, I have updates on accessing the ISO gainmap spec (ISO 21496-1), 1) ISO/TC 42 WG 18/23 will have a ballot on having a liaison to W3C. That ballot voting should end by the end of March 2025. 2) ISO 21496-1 is now in the DIS stage, meaning you can access the spec publicly now (https://www.iso.org/standard/86775.html<https://urldefense.com/v3/__https://www.iso.org/standard/86775.html__;!!PIZeeW5wscynRQ!uSOF_M-73ImQh4QayEeqnrGsM5cKQ18y5BHZG9BFZN4w2JQ3hoeeDC7a4jky7g3XIr-W1uS9seRWLEZYMtUp$>). It is at bargain bin ISO prices, costing 65 CHF (presumably because it is considered in a "draft" stage). Sincerely, Fares On Fri, Feb 28, 2025 at 9:51 AM John Bowler <john.cunningham.bowler@gmail.com<mailto:john.cunningham.bowler@gmail.com>> wrote: v4: cHRM chunk fix. Entirely backward compatible; existing decoders (ones which actually check, which libpng no longer does) will simply reject the chunk (harmless since the colourspace can't be represented anyway if the spec is adhered to rigorousely), new decoders will handle it. Restart markers; argued about over and over again. Fully supported at present but you can't do a complete parallel decode without knowing where the rows start and end. That needs some information which can be cracked; i.e. a cracker can use it to defeat a decoder which uses the restart marker. The crack is basically undetectable until all the preceding blocks have been decoded. If you just want to do LZ77 "inflate" in parallel no biggy; doesn't require anything new. Complete parallel decode would be nice but it's so quaint and it requires a critical chunk. Much much better to encode in blocks, not rows; much-much-much faster even though the underlying data is the same. Standard wisdom since the late '90s. John Bowler
Received on Friday, 28 February 2025 02:14:42 UTC