-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Honor dithering requests from UIManager #800
Conversation
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 ;). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't check the flags but the logic looks fine to me.
@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. |
@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 ;). |
Reminds me of your standard printer test page type thing: https://opensource.apple.com/source/cups/cups-136.9/cups/test/testfile.pdf |
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 ;). |
@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. |
If you want to take a break, have a look at this: https://www.youtube.com/watch?v=EySDyp1SQ-E |
@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.) |
I'd be inclined to think that's the legacy, much more iffy dithering capabilities of previous EPDC iterations ;). |
Right, good point. Ignore what I said. ;-) |
Since Mk.7 REAGL isn't FULL, but still never flashes ;).
@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. |
@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" |
@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? ;). |
Look good to me. Again sorry for the mess 😭 |
@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 ;). |
@NiLuJe Were we waiting on anything to merge this one? |
@Frenzie : Nope, it's good to go :). |
How about Aura One? Too old for this ;) ? |
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>
.
|
... 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