- From: Chris Blume (ProgramMax) <programmax@gmail.com>
- Date: Thu, 27 Feb 2025 20:25:42 -0500
- To: Fares Alhassen <falhassen@google.com>
- Cc: jbowler@acm.org, public-png@w3.org
- Message-ID: <CAG3W2KeLKRHKpNL1w4mfBBJ0t1mLQM0eyD-Ns0DR7weHcWXb8w@mail.gmail.com>
> > 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> 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). 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> 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 01:25:58 UTC