Streaks in cover images on sleep screen

[JeanPierre]

I've set my Aura ONE up to have fullscreen book covers when sleeping. I have noticed that the presence of white text on these covers results in a streaking effect where the image is lightened to either side of the text. I've attached an image to show this effect.

Is it normal for this to occur with my device, my firmware version, or is my device faulty? I'm using a patched version of 4.12.12111.

[djazz]

My KA1 has the same :/. Maybe not as strong but it is visible when it is in sleep mode.

[NiLuJe]

My best guess is it's a weird dithering quirk on Nickel's side, or quantization quirk on the EPDC's side, or a combination of both.

Would probably not happen if the cover image was properly processed to begin with .

[JeanPierre]

Originally Posted by NiLuJe

My best guess is it's a weird dithering quirk on Nickel's side, or quantization quirk on the EPDC's side, or a combination of both.

Would probably not happen if the cover image was properly processed to begin with .

I currently do some post-processing on the contents of .kobo-images on my Aura ONE to reduce the size of the images without a perceptible loss in quality—they look streaky no matter what. I currently use djpeg and cjpeg, but I also have magick.

Is there anything I can do in a similar manner after the images have been uploaded to my device by Calibre that could mitigate this effect? I was unable to build your version of Calibre, and it seems your plugin needs it to function properly.

[NiLuJe]

I essentially do this in my own Calibre build (i.e., literally calling ImageMagick, instead of relying on what Calibre has to offer like in the patch I linked to earlier. It's not portable for shit, but it works ;p).

(On the off-chance you're using Gentoo, that version of the patch is in my Portage overlay. The patch will need to be personalized, because it's using a hardcoded path to the palette ).

If you're in a hurry, and/or don't want to bother with expensive rescaling/letterboxing, and slightly more expensive error diffusion dithering, ImageMagick's -ordered-dither o8x8,16 also does wonders, and it's dirt cheap compared to what both my examples do .
And thanks to the magic of maths, it outputs stuff in the right palette without needing an explicit remap (as the palette is evenly spaced, and 255 / (16-1) == 17, meaning 0x11 in hex, which is exactly the gap between colors in the 4bpp grayscale palette used on eInk).
(Yes, it worked so well that I may have spent a bit of time porting it to FBInk recently ).

Keep in mind that you'll probably have to reboot for Nickel to pick up changes made to cover thumbnails behind its back.

There's also a possibility what you're seeing is an eInk refresh artifact based on the way Nickel shows sleep screen covers, which, on my devices is: show the image, then refresh the image again with a flash. (At least when NOT using the option that shows the "Sleeping" tag. I have no idea how this might affect the whole process, so disabling that may also be one thing to try).
That's less optimal than flashing a white screen, then flashing the image.

(In fact, with certain patterns, it can lead to hilariously bad results).

[NiLuJe]

Also, you mentioned JPEG, which, err, will not work *at all* as a storage format for dithered images, as the JPEG encoding process will essentially wreck the dithering.
You can thankfully safely switch to PNG, though, and if they're grayscaled and dithered and actually stored like that, you shouldn't see a massive difference in storage space (in fact, might even be more efficient than JPG). .

Sidebar: IIRC, Calibre already does an optimizing pass on any image it outputs, so using jpg/png crunching tools manually *should* be a fairly redundant process .

[JeanPierre]

I haven't had the opportunity to try this out yet but I thank you for the quick and informative responses you've given to my questions on both occasions