Kobo Device Driver Update

[PeterT]

And at least Kobo is very easily rooted. ☺

[davidfor]

Originally Posted by NiLuJe

First of all, sorry for digging up a relatively stale thread... .

No problem. This is the right place for this sort of discussion.

Given the terrible rendering of covers in sleep mode, I quickly enabled the "B&W Covers" setting, but when that didn't help much, I took a look at the code: it basically just does what's on the tin, without dithering it down to the eInk 16 shades of grey palette.

Since I was in a hurry, I took a very dirty approach and applied this simple patch to the Calibre sources:

diff --git a/src/calibre/utils/magick/draw.py b/src/calibre/utils/magick/draw.py
index 73832a1..d0793c4 100644
--- a/src/calibre/utils/magick/draw.py
+++ b/src/calibre/utils/magick/draw.py
@@ -75,6 +75,7 @@ def save_cover_data_to(data, path, bgcolor='#ffffff', resize_to=None,
 
     if grayscale:
         img.type = "GrayscaleType"
+        img.quantize(number_colors=16, dither=1)
         changed = True
 
     if resize_to is not None:

It's dirty as hell, but it appears to be doing the job just fine. (Granted, the quantization step is expensive and appears to block the GUI, but, it works, I can now look at book covers without making my eyes bleed ;p).

I'm basically just throwing the idea out there to see if there's a way to handle that more gracefully .

[Granted, my opinionated position on this issue most likely stems from the pains I took to do it right with the Kindle's ScreenSavers hack ]

I can't say I've noticed a problem. I haven't noticed the problem on my Glo, but it might be more noticeable on the higher resolution HD and H2O. How do the covers for kepubs from Kobo look? A preview should show it.

[NiLuJe]

@davidfor: Yup, affects vanilla covers too. The closer I could get to describing it is banding, if that makes sense for grayscale .

You can replicate the effect by reducing a grayscale image to 16 shades without dithering (which I guess is basically what the software/hardware on the Kobo is doing, since dithering is relatively expensive).

[jackie_w]

Just a comment ... after downloading images 2 and 4 (gray and dithered), my naked eye can't really see much difference when viewed on the PC. They must be different because the dithered is almost twice the filesize of the gray, its just that I don't see it. Are you saying that these 2 images do look very different when viewed on the H2O?

I agree that the 'banding' on certain images can be pretty ugly on the H2O (and previous models) if you have the calibre Kobo driver configured to send Colour rather than Black-and-white covers.

[NiLuJe]

@jackie_w: Yep, throwing image 2 without processing at an eInk controller renders more or less like what image 3 looks like (albeit probably not as awful as that one, I chose something with gradients on purpose ).

As for the differences between 2 & 4 on an LCD, I'd recommend checking them at their original size, scaling algorithms have a tendency to smooth or exacerbate dithering patterns . [Some cheap LCD screens also have crappy internal dithering, which may not help, although that usually affects video more than fixed images].

On the other hand, throwing image 4 at an eInk controller should render much more like what image 2 looks like on an LCD than image 3 .

EDIT: See for yourself, attached the same thing formatted for the Aura H2O, feed it to pickel showpic. (And reset the rotation afterwards to unbreak nickel)

cat cover_dahlia_16c_dithered.raw | /usr/local/Kobo/pickel showpic
echo 3 > /sys/class/graphics/fb0/rotate

FWIW, because that's unusual enough to be annoying to find:

avconv -i cover_dahlia_16c_dithered.png -f rawvideo -pix_fmt rgb565 -s 1440x1080 cover_dahlia_16c_dithered.raw

Input PNG has to be 8-bit, even at 16c, or ffmpeg/libav chokes on it (ie. Image > Mode > Grayscale in GIMP), and it needs to be in landscape mode (90° counter-clockwise rotation)

EDIT²: And the requisite terrible cell-phone pictures .

EDIT³: That example also seems to unearth a gamma issue when the controller is fed a full-color image... ;o).

EDIT⁴: As usual, if you go the extra mile, and use IM all the way, with the specific eInk color palette, it's even slightly better .

convert cover.jpg -rotate -90 -colorspace Lab -filter LanczosSharp -distort Resize 1440x1080 -background black -gravity center -extent 1440x1080 -colorspace Gray -limit time 60 -dither FloydSteinberg -remap ~SVN/Configs/trunk/Kindle/Touch_Hacks/ScreenSavers/src/linkss/etc/kindle_colors.gif -define png:bit-depth=8 -quality 75 cover_h2o.png

[jackie_w]

@NiLuJe, Thank you for the effort you must have put into the above post. I'd love to say I understood it all but I'd be lying

However, I did what I should have done in the first place which is to use your original colour cover on a test epub and sent it to my H2O and I did discover something quite interesting (at least to me ).

Loading the same epub with the same cover into calibre as 2 separate books, I sent both books to the H2O with the KOBOTOUCH driver config'd 2 different ways:

1. Upload covers: CHECK
   Upload Black/White covers: CHECK
   Keep cover aspect ratio: UNCHECK
2. Upload covers CHECK
   Upload Black/White covers: CHECK
   Keep cover aspect ratio CHECK

Option 1 (cover stretched to fully fit) is my normal choice (practically a hanging offence, I know ), but the great thing is that the 'banding' on the sleep/poweroff screen seems to be much less with option 1 than with option 2. Why that should be I'm not sure, but it explains why it hasn't really bothered me so far. Of course the epub page 1 rendering of the coloured cover still has ugly banding so I just quickly turn the page and forget about that.

[NiLuJe]

@jackie_w: . I did mention that was something I cared deeply about ;p. Mostly I'm making use of what I learned when working on the Kindle hack .

----

Hmm, that's... interesting. The codepath should be roughly identical on Calibre's side (the only thing that changes is the dimension used when rescaling), so my best guess would be nickel doing something stupid when the cover doesn't exactly match the device's resolution?

Meaning we should maybe also be doing the letter-boxing ourselves? >_<".

EDIT: I initially misread the code. If I follow, when Keep AR is enabled, the cover is uploaded as-is, which means nickel's in charge of scaling, which might explain the difference...

[NiLuJe]

And just for kicks, since Calibre is also using ImageMagick, we can do it right . [While I happen to like IM, note that it's not the only way, KCC happens to be doing it right w/ PIL ]

Slightly more involved patch, which remaps to the eInk palette & dithers, and does the letterboxing for fullscreen covers (provided I didn't bork my maths, looks okay on initial testing). It also happens to be dramatically faster than using quantize, so that's neat.

(This affects Calibre's magick Python/C module, so you'd need to build Calibre yourself to test this).

[JSWolf]

The problem is that not all covers are high resolution. So they have to be stretched and some covers just won't look good stretched.

[GeoffR]

I haven't tested it, but recent Kobo firmware (since 3.11.0 I think) has a ShouldDither feature setting.

[NiLuJe]

@JSWolf: Calibre happens to be defaulting to a fairly decent (in terms of speed/quality tradeoff) scaling algorithm, so when we do scale (on vanilla Calibre, always, except for sleep covers w/ Keep AR enabled), we're likely doing a better job than the Kobo .

@GeoffR: That's unfortunately fairly vague without a description. OTOH, that might also refer to some funky eink waveform refresh update modes (granted, that's fairly low-level, so unlikely, but who knows ;p). Good to know nonetheless .

[JSWolf]

Originally Posted by GeoffR

I haven't tested it, but recent Kobo firmware (since 3.11.0 I think) has a ShouldDither feature setting.

Where does ShouldDither go in the settings?

[JSWolf]

Originally Posted by NiLuJe

@JSWolf: Calibre happens to be defaulting to a fairly decent (in terms of speed/quality tradeoff) scaling algorithm, so when we do scale (on vanilla Calibre, always, except for sleep covers w/ Keep AR enabled), we're likely doing a better job than the Kobo .

One thing I've been doing is replacing low resolution covers with high resolution covers. Amazon can be good for that. If there is a high resolution cover at Amazon for the Kindle edition, it will be 1500 lines. I also use Google search to look for high resolution covers if I cannot find at Amazon.

[davidfor]

Originally Posted by NiLuJe

And just for kicks, since Calibre is also using ImageMagick, we can do it right . [While I happen to like IM, note that it's not the only way, KCC happens to be doing it right w/ PIL ]

Slightly more involved patch, which remaps to the eInk palette & dithers, and does the letterboxing for fullscreen covers (provided I didn't bork my maths, looks okay on initial testing). It also happens to be dramatically faster than using quantize, so that's neat.

(This affects Calibre's magick Python/C module, so you'd need to build Calibre yourself to test this).

Unfortunately I don't have a C environment to build that, so I can't test it. But, I had a quick look at the patch file. A lot of the changes seem to be line-end differences. Or am I misreading it?

I hadn't noticed the "minify_to" parameter before before. I'll have to check, but it should just be taking the size defined for the cover rather than the earlier calculation. And I think the full size cover needs to be handled as well. At the moment, if the aspect ratio is being kept, it isn't being resized, but it probably should.

There's something about the letterboxing I don't like. I'm not sure what it is, just that I don't like it. Hopefully I'll work out what when I play with it a little.

[NiLuJe]

@davidfor: There's a fair bit of whitespace killing noise in the patch, yes (blame that on my text editor settings). I'm wary of building a diff with bB to skip those because that might be critical for Python code, and end up generating a broken diff. I'll check, though .

minify_to: Yeah, that's basically the bounding box/canvas size. In this case, it pretty much always should match the exact size we're scaling to, *except* when doing letterboxing. Which is (hopefully) how the patch is using it.

Full size scaling w/ Keep AR: Yep, agreed, which is what's the patch also doing (granted, only if uploadgrayscale is enabled right now) .

EDIT: There, patch should be less noisy .

EDIT²: v3, which switches the scaling algorithm to Lanczos for eink covers. Slightly sharper, and the downside of slightly more ringing is usually alleviated by the dithering. Performance should be comparable.

EDIT³: v4, mostly nothing new. Just confirmed that we can't avoid the extra scaling pass made by nickel itself when it adds the deadzone covered by the bezel on the Aura & H2O.

EDIT⁴: v5, made the letterboxing optional. Still looks good on my H2O, and looks better with full screen sleep covers disabled on the Kobo.
cf. #247 for examples.

EDIT⁵: v6, 3 years later . Ported to the current Calibre codebase .
This no longer needs to patch C/C++ code, so it's pure Python.
Also a tiny patch to the Kobo Utilities plugin to make testing the letterboxing codepath easier.

EDIT⁶: v7, now with PNG support, because that just makes much more sense, and it happens to work flawlessly on my device .

EDIT⁷: v8, achieved pixel-perfect results w/ letterboxing on my H2O, despite its quirky top 11px .

EDIT⁸: v9, double-checked the other thumbnails size on my H2O, while I was there. One was off by 2px, the horror! .

EDIT⁹: v10, inconsequential tweak to a string.

EDIT¹⁰: v11, rebased against Calibre 3.36.0, fixed a few letterboxing issues, and reintroduced dithering as a dedicated option, following some tests on FW 4.12...

EDIT¹¹: v13, a few code cleanups, and made the new settings more robust to make nonsensical combinations impossible.

EDIT¹²: Refreshed KoboUtilities for v13 .

EDIT¹³: Resynced KoboUtilities w/ v2.7.0 .

EDIT¹⁴: Resynced KoboUtilities w/ v2.8.0 .

EDIT¹⁵: v16, revamped dimension computations, greatly enhanced dithering, better PNG encodes.

EDIT¹⁶: Tweaked the PNG encoding process to speed it up (twice as fast as the first v16 implementation).

EDIT¹⁷: Latest iteration in the Calibre PR .

EDIT¹⁸: Tweaked KoboUtilities checkbox layout to match latest driver changes.

EDIT¹⁹: This is now included in Calibre >= 3.44.0 .

EDIT²⁰: This is now included in Kobo Utilities >= 2.9.0 .