koreader
FR: Night Mode: don't invert originally dark documents
Does your feature request involve difficulty completing a task? Please describe.
This might be considered a bug instead. I have some HTML files with dark backgrounds. On non e-ink Android devices I turn on 'night mode' with the intent that everything is readable in the dark (i.e. black background). This works most of the time, but for at least HTML files, it seems to invert the background, so if it was dark to begin with, it becomes very bright.
(This also means these same HTML files render as white letters on dark when in 'light mode' on e-ink devices. I'm not sure what the behavior here should be since that's the color of the HTML background after all).
Describe the solution you'd like
Smarter night mode that preserves the dark background when in night mode. Maybe some way to display originally-dark modes in a light manner when in light mode, but unsure.
Describe alternatives you've considered
For reflowable documents like HTML, I found that setting Document -> Style tweaks -> Miscellaneous -> Pure black and white might work for this. Maybe that's a good solution, but something more automatic would be nice. And I don't believe this would work for e.g. a PDF with a dark background.
I'm not sure what the behavior here should be since that's the color of the HTML background after all).
Indeed, after all :) We display what the publisher tells us to.
Pure black and white might work for this.
That's what I was going to suggest.
Maybe that's a good solution, but something more automatic would be nice.
Well, we can't, really. We get bitmaps of the original document from the rendering engines, rendered as expected. The nightmode effect is done at the tail end of the process, when that bitmap + our frontend additions (highlight, etc...) is fed to the screen (inversion being done by the hardware, or by us in software when hw-inversion is not available, still at this tail end). Nowhere we have some detection of the content, like its white/black level, of bitmaps or the document itself, to possibly tweak that behaviour - and if we had such an "automatic" feature, it would probably make a lot of bad decisions... So, best left to the user and style tweaks. (And maybe PDFs could have a per-book option to not follow nightmode, by inverting the bitmap before its fed to be inverted back by nightmode, like we do for images in Imageviewer.)
Sounds good, reasoning makes sense. If I had a ton of dark-mode documents it would get annoying.
(And maybe PDFs could have a per-book option to not follow nightmode, by inverting the bitmap before its fed to be inverted back by nightmode, like we do for images in Imageviewer.)
This might be nice, or some equivalent of 'Pure black and white' for fixed documents that apply specifically to one document. What about a separate inverter similar to current night-mode that applies just to the single document rendered (not e.g. menu settings when the document is open)?
For the most part per-document tweaks are fine. Would be harder if someone had hundreds of dark-default docs, but I don't.
Fighting nightmode by inverting the bitmap near the end may not be the right solution to the issue (it may work for your simple case, but it's probably limited). Ideally, it should be done by our kopt stuff: it's the bit of code that takes the pristine image from MuPDF, and ensure all our post-processing features like detecting margins for auto cropping (unless it's our code?), dewatermarking, reflow... It feels like this inversion should be another post-processing feature of it. I dunno how autocrop works on black pages, but if it fails detecting margins on a black page, it's a proof tail-end-inversion is not the right solution : it should happen early, so margin detection work on a white page. Our library is based on https://www.willus.com/k2pdfopt/, and among its options https://www.willus.com/k2pdfopt/help/options.shtml, there is:
-neg[-|+] Inverse [don't inverse] the output images (white letters
on black background, or "night mode"). If -neg+, inverts
all graphics no matter what. If just -neg, attempts to
invert text only and not figures. Default = -neg-.
See also -colorbg and -colorfg.
which could do things for us - but as it says "output images", it may be done at the end and may not solve the margin issue (if it exists). Letting that investigation to the interested user :)
I would love it if we can just not have PDFs inverted when in night mode as an option either globally or per file
