I notice the container has no ICC profile support. Trivial do add as an extension tag, but should definitely be in the first spec IMO. And if I read this correctly, extension tags are hardcoded as numbers, rather than using a tag name. I don't think that's a good idea.
The BPG spec says, "Arbitrary meta data (such as EXIF) are supported." This isn't good enough. Modern formats need to specify how ICC profile format information is to be embedded, under what circumstances, and smaller space alternatives (similar to DCF and EXIF color space tags). Otherwise this is like JFIF, where it's the ICC spec and not the JFIF spec that describes how ICC profiles are to be embedded. To replace JPEG and PNG, the BPG spec needs to define such things itself rather than deferring the work to others or making it optional. Image color space data isn't optional if high quality is to be taken seriously, and for that matter the encoding of copyright and image provenance information needs to be defined in the spec also.
Yes, that makes it even stranger. Why use an unsigned 4-byte integer when tags are mapped to a number internally. Unless they anticipate to map more than 2^8-1 or 2^16-1 different tags.
Maybe I'm reading it wrong.
extension_tag ue7(32)
...
'extension_tag' is the extension tag. The following values are defined:
1: EXIF data.
PS. I think I understand now. It's just meant as a shortcut. Not sure why this is done when EXIF fits just as well.
Is there a situation where 14-bit sRGB isn't enough? There are a lot of weird color matching issues on the web caused by inconsistent application of ICC profiles to PNG images by different browsers / platforms.
Storing HDR images, where the brightest parts are greater than 1.0. That way, when you later edit the image and adjust the levels, new detail comes into view. OpenEXR is the best we have for this now. It uses half-precision 16-bit floating point color components.
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.
