Honor dithering requests from UIManager

[NiLuJe]

... on supported devices.

That is:

Kindle: KOA2+ (KOA2, PW4)
Kobo: Mk.7+ (Clara, Forma)

Possibly Cervantes 3 & 4, but the required "new" codepath isn't implemented in KO (pinging @pazos) ;).

Used by KO#4541

[NiLuJe]

If someone's looking for technical details, this is an EPDC V2 feature, which does quantization + ordered dithering, with a fairly nice pattern.

I'd already noticed that simple ordered dithering patterns were more than "good-enough" on eInk screens, even as far back as on Pearl screens, but this one is really pretty decent.

Even throwing a nasty testcase full of gradients at it leads to pretty good results!

And that's coming from a guy that really cares about this stuff ;).

The latest version of FBInk can toggle this on demand, if you're looking for a standalone test on your own data ;).

[Frenzie]

I didn't check the flags but the logic looks fine to me.

[pazos]

Possibly Cervantes 3 & 4, but the required "new" codepath isn't implemented in KO

@NiLuJe: I don't want to mess with my main reader, plus I remember I tried some dithering calls (x1, x4, ntx_d8) and they were awful.

[NiLuJe]

@pazos : I was thinking of what amounts to the Mk. 7 codepath (which you implemented in FBInk), not those weird and legacy flags which date back to the equally weird and esoteric Aura, IIRC ;).

Namely, the new update_data struct with the dither_mode/quant_bit fields (and the mxcfb_dithering_mode enum), not the old, quirky and indeed potentially horribly broken legacy EPDC_FLAG ones ;).

[NiLuJe]

It's hidden behind the -D flag in FBInk, if you want to try it out on your device.

And here's my usual torture test, thanks to jackie_w on MR ;).

(To begin with, it shouldn't show any form of banding on any decent LCD screen, FWIW. It didn't even on my old PVA screen with a 6bit panel (meaning there was dithering involved at the panel and/or graphics card level)!).

[Frenzie]

Reminds me of your standard printer test page type thing:

https://opensource.apple.com/source/cups/cups-136.9/cups/test/testfile.pdf

[NiLuJe]

It has the added benefit of having a large magenta section, which is a nice color to pickup differences in greyscaling methods (it ends up looking fairly different depending on whether you gamma-correct grayscale, or do it in linear light).

Which was a bonus point, in my case ;).

I have a full archive of dithering experiments in Nickel over here, especially as far as full-screen covers are concerned ;).

[NiLuJe]

@pazos : Speaking of, given the age of the Cervantes 3, if that 2016 mention is accurate, I'd be inclined to think only the Cervantes 4 could actually support that codepath?

EDIT: While the REAGL mention possibly makes more sense, especially if it was based on the same board as the Aura.

[Frenzie]

If you want to take a break, have a look at this: https://www.youtube.com/watch?v=EySDyp1SQ-E

[Frenzie]

@pazos Is https://github.com/koreader/android-luajit-launcher/blob/14f9c2491d181db34ed694e0b9a7d307762919be/src/org/koreader/device/rockchip/RK30xxEPDController.java#L47 the same thing? (If so, in the long term Android could tap into this as well.)

[NiLuJe]

I'd be inclined to think that's the legacy, much more iffy dithering capabilities of previous EPDC iterations ;).

[Frenzie]

Right, good point. Ignore what I said. ;-)

[pazos]

I was thinking of what amounts to the Mk. 7 codepath (which you implemented in FBInk), not those weird and legacy flags which date back to the equally weird and esoteric Aura, IIRC ;).

Speaking of, given the age of the Cervantes 3, if that 2016 mention is accurate, I'd be inclined to think only the Cervantes 4 could actually support that codepath?

@NiLuJe: yeah, the code in FBInk is broken, it just works because it is never called (I bet you can find why), I will submit a patch when I have some time. So no, the new codepath won't be supported in current cervantes models, sorry for the mess :p

@Frenzie: i didn't test the Dither mode on Android, but I think it will be broken like any other EPD mode in the controller. The only one that worked (other than FULL or black2white) was A2, which was nice for scrolling but a real pain for fast page turning. Probably things are better with recent devices.

[NiLuJe]

@pazos : Even on a Cervantes 4? (Just double-checking, Q4 2017 sounds a tiiiiny bit early, though ;)).

Where did the mxcfb header stuff come from then, Kobo?

Because, yeah, right now, I wouldn't say that it's never called, unless I'm reading things wrong, it's kind of worse: the "classic" MXCFB_SEND_UPDATE ioctl is called, but with a struct full of the "new" stuff.
Why that doesn't horribly blow up is beyond me ;).

[NiLuJe]

@pazos: Ah, found the Kernels ;).

So I just tried to clear that up in FBInk (bascially getting rid of the cervantes_new codepath, which should match KOReader's behavior), could you check that I didn't do anything stupid when you have the time? ;).

[pazos]

So I just tried to clear that up in FBInk (bascially getting rid of the cervantes_new codepath, which should match KOReader's behavior), could you check that I didn't do anything stupid when you have the time? ;)

Look good to me. Again sorry for the mess 😭

[NiLuJe]

@pazos : 🎉

No worries, I remember how the Aura quirks threw me for a loop at the time, and this turned out to be fairly similar ;).

[Frenzie]

@NiLuJe Were we waiting on anything to merge this one?

[NiLuJe]

@Frenzie : Nope, it's good to go :).

[ptrm]

How about Aura One? Too old for this ;) ?

[NiLuJe]

Yep, Mk. 7 only ;).

…

On Fri, Feb 8, 2019, 08:05 Piotrek Marciniak ***@***.*** wrote: How about Aura One? Too old for this ;) ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#800 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG1Zk81hTatylv_tx8OYL1x9H1jX4LOks5vLSGxgaJpZM4aezkG> .