KePub reader reports colour media on e-ink

[GeoffR]

I have a small number of books with colour images that look good on a colour display but very bad on a greyscale display, so I want to make custom greyscale images that only display on greyscale devices, and continue to display the colour images on colour-capable devices.

I made an ePub book that checks whether the display is colour-capable, and can select the appropriate image. It uses @media queries and Adobe XPGT conditionals so should work on both of Kobo's readers, ePub and KePub, and It also seems to work okay in Calibre. But I noticed that on my Glo the KePub reader is reporting that it has a colour display.

(Edit: I should add that the firmware version is 4.8.11073)

Maybe I don't understand how the @media queries work? Or maybe it is a problem with the KePub reader? This is the query code I used:

div.display-iff-color-unknown { display: block; }
div.display-iff-color { display: none; }
div.display-iff-not-color { display: none; }

@media (color) {
    div.display-iff-color-unknown { display: none; }
    div.display-iff-color { display: block; }
    div.display-iff-not-color { display: none; }
}

@media (max-color: 0) {
    div.display-iff-color-unknown { display: none; }
    div.display-iff-not-color { display: block; }
    div.display-iff-color { display: none; }
}

and the HTML to show the result:

  <div class="display-iff-color-unknown">
    <p>Color: Unknown</p>
  </div>
  <div class="display-iff-color">
    <p>Color: Yes</p>
  </div>
  <div class="display-iff-not-color">
    <p>Color: No</p>
  </div>

Attached is a simple ePub example (Edit: Updated to fix ePub orientation result, didn't affect KePub color result.)

[sherman]

Maybe it has to do with the fact that Nickel uses a full colour framebuffer?

If the kepub webkit renderer is determining colour information from the linux framebuffer, it will believe the screen is colour.

I don't really know though. Just a theory.

[davidfor]

I just tried this on my Aura ONE as both epub and kepub and am getting the same results. I'm on a much newer firmware, but, I don't think this will have changed. What @sherman suggested is what I thought when I saw the results. In fact, I was surprised it worked for the epub.

One thing I noticed is that for the epub in landscape mode, the orientation line wasn't displayed at all.

[GeoffR]

Originally Posted by sherman

Maybe it has to do with the fact that Nickel uses a full colour framebuffer?

If the kepub webkit renderer is determining colour information from the linux framebuffer, it will believe the screen is colour.

I don't really know though. Just a theory.

That sounds like a good theory.

[GeoffR]

Originally Posted by davidfor

One thing I noticed is that for the epub in landscape mode, the orientation line wasn't displayed at all.

Thanks, I think I have fixed that now, have updated the attachment in my first post if you want to try it again.

[Quoth]

Screenshots on the Kobo H2O original are in colour.

Detecting if a display is colour or mono is an inherently dubious idea. Better to test what covers look like in mono, or even 16 shade mono. Easy in any image editing program.

You can use a "best" colour image for covers on the websites listing books. Often anyway a good mono image is automatic with a good colour image, if the mono is poor it suggests the shadows, highlights and general contrast is poor in the colour version.

[GeoffR]

Originally Posted by FrustratedReader

You can use a "best" colour image for covers on the websites listing books. Often anyway a good mono image is automatic with a good colour image, if the mono is poor it suggests the shadows, highlights and general contrast is poor in the colour version.

I haven't actually had much problem with covers, I think the publishers tend to make covers high-contrast anyway so they stand out in the bookshop (at least, they would if every other book in the shop didn't also have a high-contrast cover.)

But there is some interior artwork that looks nice in colour but is fairly low-contrast, or just uses colours which don't look right when translated to greyscale by the usual algorithms. They are not poor-quality scans, I think it is how the artist intended them to look, just that they were never intended to be viewed in greyscale.


Anyway I think I have a solution: Since the colour-capability of a device doesn't change, I could make the colour images the default and use Calibre's kobo_extra.css method to override the default when sending books to a device that doesn't support colour.

[davidfor]

Originally Posted by FrustratedReader

Screenshots on the Kobo H2O original are in colour.

Detecting if a display is colour or mono is an inherently dubious idea. Better to test what covers look like in mono, or even 16 shade mono. Easy in any image editing program.

You can use a "best" colour image for covers on the websites listing books. Often anyway a good mono image is automatic with a good colour image, if the mono is poor it suggests the shadows, highlights and general contrast is poor in the colour version.

This isn't about covers. @GeoffR said "books with colour images". And it is about experimenting. Until you know what can be done, and what it looks like, you can't be sure of what is the best thing to do.

[NiLuJe]

Note that (at least on kepubs), Mk. 7 devices will hardware dither images with a nice ordered dither pattern, which does the job fairly nicely for those cases when you can't/don't control the image processing pipeline .

EDIT: And this is how it looks in a worst case scenario.