Paperwhite 2018 looks worse than 2013? (Picture inside)

[NiLuJe]

@j.p.s: Yeah, I'm wary of wording it that way, because we're really not (intentionally) displaying anything other than those specific 16 shades of gray. We're just tricking our brain into making it seem so.

The eInk tech itself happens to lend itself very well to the sort of pattern dithering produces, which certainly helps the illusion, too.

----

Note that, on crappy LCDs (older 7bpc+1, which did dithering on their own to fake 8bpc), you could actually detect banding on some gradients (or dithering artefacts/jitter, depending on how it was implemented).

The same thing is true today for cheap fakeish (8bpc+2) HDR displays. But HDR is a vastly more complex issue, so let's not go there (spoiler: it's a mess) ^^.

[j.p.s]

Originally Posted by NiLuJe

Unfortunately, we can't do what you're requesting, as I mentioned elsewhere (or here, earlier): the hardware dithering is done on a work buffer that won't make it back to the framebuffer, so we can't capture it to try it elsewhere .

If you meant the dithering applied by Calibre, on the other hand, here goes.

I was taking jswolf's claim that putting an image as an ebook cover and processing it with a kobo can produce a dithered image file at face value. If that is not the case, please contradict his post.

[NiLuJe]

@j.p.s: It's true in two different ways:

* No matter what you feed it, when Kobo displays an image, it will be dithered. On newer devices, by the hardware, on older devices by the kernel and/or nickel.

* The Calibre Kobo driver can pre-process the book's cover, but only the copy that's used for the device's sleep screen (which will then again go through the dithering pass I mentioned earlier when it gets displayed by the device). Those files are accessible by the user, which is what I think mattered here for Jon, because it meant someone could get their hands on a ready-to-use properly dithered image.

As Is mentioned in an edit, that's an extremely roundabout way to achieve that end result, if you have access to ImageMagick .

(Momentous event: I think I'm agreeing with Jon on something ).

[Gametaku]

Originally Posted by NiLuJe

Text comparisons would be harder to make "objective", as the text renderer itself will be different between different brands.

Unless you compare KOReader vs. KOReader on each device, with the same settings .

But that introduces another variable that probably won't answer the original question anymore ^^

Bought the Libra (need probably a week or more to reach me) as a replacement for the PW4 as it was mentioned here that it has the best contrast among the 3 devices.

I will mainly be using it for text reading. Default device reader vs default device reader comparison is good enough for me.

[NiLuJe]

@Gametaku: Which is fair and what most people would expect, that's just me being extremely nitpicky in mentioning that such a test couldn't technically be objective .

[j.p.s]

Originally Posted by NiLuJe

@j.p.s: Yeah, I'm wary of wording it that way, because we're really not (intentionally) displaying anything other than those specific 16 shades of gray. We're just tricking our brain into making it seem so.

The eInk tech itself happens to lend itself very well to the sort of pattern dithering produces, which certainly helps the illusion, too.

To me, the connotation difference between effective and actual is illustrated by"
"Combining red light and green light effectively produces yellow light, but actually it does not." (Disregarding any language system which might define red light + green light as yellow light. Please assume for the purposes of this discussion that yellow light is strictly the range of monochromatic light that stimulate the perception of yellow.)

Note that, on crappy LCDs (older 7bpc+1, which did dithering on their own to fake 8bpc), you could actually detect banding on some gradients (or dithering artefacts/jitter, depending on how it was implemented).

The same thing is true today for cheap fakeish (8bpc+2) HDR displays. But HDR is a vastly more complex issue, so let's not go there (spoiler: it's a mess) ^^.

Well, for some program material, I can see banding on my SDR OLED TV.

[NiLuJe]

@j.p.s: Okay, so, yeah, we're agreed that my use of effective was confusing then .

----

Oh, the fact that the video content itself might already show banding artifacts is also quite likely, true. But technically another issue, because the source is already flawed in these cases .
Again, another vast subject I'll refrain from launching on, because it truly would be completely OT then, and we're already skating the line ^^.

[JSWolf]

How do I add PNG images to a Kindle to display?

[NiLuJe]

@JSWolf: I don't actually recall if:

* Just dropping a PNG in documents would make it show up
* Whether CBZ are supported
* If any of those happen to work, whether you actually have a way to make it show *unscaled* so that any of this can mean anything (I'm going to go out on a limb and say "no", though).

(I have a really fuzzy memory of there being a hidden image viewer somewhere, somehow, but that was seventy billion FW versions ago).

So I'm afraid I have no better solution than:

* Build a test <whatever format KCC outputs on Kindle> with KCC (assuming you can convince it not to process it in any destructive way, which seems kinda counter productive given its mission statement, so, eeeh.)

OR

* Display it with eips/fbink if you have shell access.


I know which one I'd go with, but that's me ;p.

TL;DR: Thanks Jeff, Kindles are awesome. >_<".

[binaryhermit]

I think emailing it to your send-to-kindle works, perhaps with conversion.

[NiLuJe]

Oh, yeah, it'd definitely get mauled to death that way .

[j.p.s]

Originally Posted by JSWolf

How do I add PNG images to a Kindle to display?

It has changed over time. Sometimes putting a JPEG, GIF, or PNG in the images directory in the root of the mounted kindle file system works and sometimes the required directory is pictures . Either has to be created because they are not there by default. It has been a long time, so I don't know what contemporary kindles require.

But that is the easy part for kindle owners. Where is an example of an image file made with the magical kobo dithering?

[ilovejedd]

Originally Posted by NiLuJe

@JSWolf: I don't actually recall if:

* Just dropping a PNG in documents would make it show up NO
* Whether CBZ are supported NO

* Build a test <whatever format KCC outputs on Kindle> with KCC (assuming you can convince it not to process it in any destructive way, which seems kinda counter productive given its mission statement, so, eeeh.) NO, well technically might be possible if running CLI from source. The GUI crops the heck out of images and there's no way to override in GUI.

[JSWolf]

I figured out the easiest way to do it. I made the image a cover for the PW3.

OK, here is NiLuJe's Trouble PNG in color on my Aura H2O (1st ed.) and on a PW3. The image on the left is the H2O and on the right is the PW3.

You can see that the H2O has dithered the image better then the PW3.

[NiLuJe]

... because Nickel always dithers image content on its own (inline, cover, sleep, roughly all the things that matter in current FW revisions. Speaking of the KePub renderer, because I won't touch ePubs with a ten-foot pole on Kobo), which we already knew ^^.

*How* it actually does that depends heavily on the specific device, though (and on the FW version. It used to be worse. Which, ironically, was slightly better if your content was pre-processed properly ^^).

(On the H2O, it's easy: there's no hardware/kernel support for it, so it's all Nickel).