Epub-specs: Core Media Types: Disallow CMYK images

[tofi86]

We have a feature request for EpubCheck for reporting CMYK images as ERROR: https://github.com/IDPF/epubcheck/issues/692

However, Core Media Types in the spec doesn't define RGB or CMYK or GRAYSCALE color profiles.

While RGB and GRAYSCALE is supported on all readers, CMYK images are not supported on most of the current eReading hardware and will fail the image to load at all.

Any chance that a further revision of the EPUB spec my specify that?

[dauwhe]

I don't think we should forbid CMYK images in EPUB. Every browser I've tried supports CMYK in JPEG, at least. Most EPUB reading systems based on browser engines shouldn't have trouble with such images (tested just now on iBooks, Azardi, Calibre, and Kindle Previewer).

Perhaps avoiding CMYK is more of a best practice, given the limitations of some older reading systems?

[tofi86]

CMYK is a colour profile specially developed for print media. CMYK images in electronic books are just a remnant of print workflows that have been improperly converted for a digital product. Therefore the CMYK profile in images shall be forbidden in eBooks.

[atroia]

I agree, I prefer keeping print media and digital media color spaces separate.

[dauwhe]

I'm realizing that we can't change this even if we wanted to. We cannot make existing valid EPUB 3.0.1 files invalid with this revision.

Does anyone know if the old epubpreflight checked for this?

[shorshe]

What about a warning ⚠️ instead?

[GarthConboy]

Agree we Dave above, can't render 3.0.1 EPUB's invalid with this version. Possible to make CMYK profile a SHOULD NOT, which would potentially yield a warning (or info) in epubcheck. But, I'd be somewhat leery to do so, as I don't know how prevalent CMYK is in practice, and it works pretty much everywhere.

[mkraetke]

The HTML5 picture element allows to include multiple source elements which provide image versions for different output channels. You can specify a media query for each source element. Perhaps your EPUB features a PrintCSS along with alternative CMYK images, you may think of this markup.

<picture>
  <source srcset="rubycat_cmyk.png" media="print and (resolution:300dpi)"/>
  <img src="rubycat_rgb.png" alt="cat content from tofi"/>
</picture>

Even if EPUBs with PrintCSS and CMYK images are a pure hypothetical case, this could be an interesting feature for publishers in the near future. However, I don't have a printer at hand and couldn't check if my example is supported by any web browser.

[tofi86]

I'm realizing that we can't change this even if we wanted to. We cannot make existing valid EPUB 3.0.1 files invalid with this revision.

Bummer!

Possible to make CMYK profile a SHOULD NOT, which would potentially yield a warning (or info) in epubcheck.

+1. I'd love to see that change.

Perhaps your EPUB features a PrintCSS along with alternative CMYK images, you may think of this markup.

Interesting idea. But maybe jsut too hyphotethic. Tried something like that once, didn't went very well, never did it again and haven't seen something like that either out there in the wild yet.

[JayPanoz]

Interesting idea. But maybe jsut too hyphotethic. Tried something like that once, didn't went very well, never did it again and haven't seen something like that either out there in the wild yet.

From experience, it’s already chocking when trying to load SD/HD/SuperHD images depending on the resolution in some apps supporting it so that could explain why you don’t see it in the wild. That being said, it’ll have to be fixed sooner or later…

Back to the original issue.

As anecdata, I can recall CMYK being one super mega painful issue back in my newbie days – because 1. it’s not obvious when you didn’t produce the file yourself/authoring software did it ”wrong“ and 2. there are many possible roots to the issue when it comes to images.

In hindsight, it would have helped tremendously if that were signaled in ePubCheck – and would honestly have saved me hours of debugging.

[mkraetke]

I'm fine if epubcheck creates a warning for CMYK. However, I wouldn't like to see this as part of upcoming standards as EPUBs with PrintCSS and alternative image versions seem not so unlikely to me. However, it's worth to mention that proper image analysis would add a further level of complexity to the implementation, even if there exist some libraries like JMagick or TwelveMonkeys.

[laudrain]

As epubcheck don't check CMYK images and some retailers QA did reject our EPUB files with that kind of color profile, we added a long time ago our own checking tool upstream to verify that no image is CMYK in any of our EPUB.

I am in favor of a more explicit "SHOULD NOT" for this CMYK profile in our Core Media Types.

[rakutenjeff]

I would like epubcheck create a warning for CMYK and in spec we add "SHOULD NOT" for CMYK in Core Media Types. There is still some latest version of web browser can not display CMYK image in correct color (as example https://i.imgur.com/z6t7BKW.jpg from https://github.com/ccseer/Seer/issues/31). I tried it on FF v60 on Windows 10. My concern is once we add support CMYK in Core Media Types we might have publisher complain about our reading system can not display correctly. And I do remember we did have issue reported with CMYK images since a while ago.

[rakutenjeff]

I also don't think CMYK should be handled by implementer separately. If there is a common (can cover a range of reading system) best practice document and epubcheck could check that part it would be good enough since it considered a range of reading system. The risk that each reading system to handle CMYK or alert about CMYK image to creator is each vendor would create their own subset of standard and have to create our extension of epubchecker. And creator would need to double or triple their work of content validation and we reading system also have to do same thing. To avoid this situation, at least we need to add something in spec to let epubcheck to warn creator about this type of image. This would help whole industry.

We also can not just leave CMYK there just because UA silently support or fail it. Or why we need to define Core Media Types in epub spec even though UA could support more?

[dauwhe]

Closing as we can't change the spec for this. There are currently some discussions in the business group about ways of checking for things that are not forbidden by the specs, such as low-res images. CMYK seems to fall into that category.