BPG supports CMYK, and to re-render CMYK correctly (on a display, or an inkjet printer) means ICC support is mandatory. Otherwise, there's no point supporting C

BPG supports CMYK, and to re-render CMYK correctly (on a display, or an inkjet printer) means ICC support is mandatory. Otherwise, there's no point supporting CMYK at all. sRGB is designed for an 8 bit per channel encoding, so while it makes sense to support 10bpc to mitigate quantization effects of higher compression, it makes little sense to support more than 10bpc unless wider gamut spaces are supported. If the intent is for BPG to replace JPEG in-camera renderings, rather than converting existing JPEG and PNG to BPG, then it needs to support spaces other than sRGB. This doesn't require explicitly embedding ICC profiles but the spec needs to, well, specify at least one way of preserving this metadata. Otherwise there's no guidance for encoding or decoding the information, and then it's lost. And at that point it's a huge regression from what we have now, and thus no point in implementing it.