CMYK jpeg handling

[padenot]

This is fairly common whenever print is involved, this needs to be handled (related to #200).

Generally it would be useful to specify how pixel format are going to work, use-cases that are slightly more advanced than just displaying the image.

I think there was an agreement that "raw" images would be available, but at that time, image handling wasn't in scope.

[dalecurtis]

The motto so far has been to avoid implicit operations wherever possible. So in an ideal world we'd have a new CMYK pixel format. Can you describe some use cases where someone would want to use a CMYK image in its native format? Thus far we've been expecting only YUV and RGB formats of varying depth.

In Chrome's implementation today (and <img>) CMYK is always converted to RGB.

[chcunningham]

Triage note: marking 'extension' as a adding a new format is not breaking.

[padenot]

Agreed, but it's only an extension if those files are rejected. Otherwise, what happens when decoding them needs to be specified.

[padenot]

Agreed, but it's only an extension if those files are rejected. Otherwise, what happens when decoding them needs to be specified.

No I'm incorrect, it's what happens when drawn: https://w3c.github.io/webcodecs/#dictdef-imagedecoderinit, but it isn't clear what happens when read-back.

[dalecurtis]

I don't think we need any additional language for drawing, that should be in the specs that handle drawing. I.e., canvas says all things are converted to srgb today, so that would continue to be the case for images here. Some later spec which accepts CMYK should expect the frames will be drawn natively in CMYK.

I don't think we should specify what output formats a client can expect from readback. I think that ties the hands of implementers to offer the most efficient output format. E.g., consider some hardware decoder that always outputs RGB regardless of the image source type. We wouldn't want a user agent to be forced to use a software decoder.

I'd say the output format is user agent and platform specific. As that's the same case is it is for hardware decoding. Long term we'll want to offer a conversion API so folks can get whatever format they want.