-
Notifications
You must be signed in to change notification settings - Fork 213
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
A better page number-crop algorithm. (Manga) #709
base: master
Are you sure you want to change the base?
Conversation
Wow this looks incredible, might take me a while to fully review it though. For reference, my perspective is mostly using a Kindle Scribe 10" which doesn't need to zoom or crop at all. But when I use smaller devices like an android Hisense a9 eink phone cropping is essential. Have you looked into any android manga reading software? I bet they might like a feature like this, and maybe they have something similar. And what platform did you develop on? I use macOS (arm64/apple silicon). And do you you have a general idea of the performance difference and how much increases the binary size? Aka ’python setup.py build_binary’ |
I hope it would actually work for others, I tested it on 30+ images from 5-6 different Mangas. I want to try it on some more Mangas before I'll continue.
Very shallowly. I tried to search on Google for some existing manga or comic crop algorithms, even some general manga-readers apps, But couldn't find something meaningful (aside of the standard cropping). I usually read on my PC or my [used to have] first gen Kindle Paperwhite 6" (as you can understand my constraint here). Recently, my Kindle's screen shattered and I've ordered a new e-reader with a 7.8" screen. I've yet to receive it so in the meantime I thought I would at least try to optimize the Mangas that I plan to read/load when I get it. Hence, I tried to write this algorithm.
I use an old Windows 10 laptop (intel x86-64)
TBH, I forgot to measure the binary, so I ran it just now to see. Regarding performance, to my surprise, it didn't suffer much of a hit, I did multiple types of benchmarks.
By the way, |
2. Add dependency to the setup.py: Numpy
… to handle thin fonts.
I don't know about having numpy replacement functions... |
While I agree, I thought we wanted to optimize output file size (as numpy increases it by 30%). Do you want me to add the NumPy version back? Unrelated - I've detected that the algorithm sometimes fails on thin fonts and single-digit page numbers. Also, there is an issue with using higher power levels that causes the page number to become distorted and the algorithm fails to detect it (currently I'm optimizing power=1 to work the best in most cases). |
That's great! Excuse me, is the Cropping mode value Cropping Power: 2 in KCC's current version of the cropping mode that corresponds to the Power3 you're demonstrating? |
Hi! No, the power levels [0...3] that I'm using are different entirely from the current power levels of [0...2] that exist currently in KCC v6.1.0. I've noted that in the issues at the bottom of OP.
|
Ok, so how should I use the algorithm you provided in KCC? I felt it was fantastic, just what I needed. Or, can you help me provide a KCCexe file that supports this algorithm? |
@neyney10 Enable GitHub Actions on your fork. Then create a release on your fork, which triggers GitHub actions to create binaries for all supported platforms, like here" https://github.com/axu2/kcc/releases Also, feel free to build a numpy version so we can more easily see the size difference across platforms. Edit: built myself: |
I have used the better optimization algorithm you provided and it is really great! Thank you very much! |
I did it. Thank you |
@zhaohengkang feel free to upload some comparison photos. |
320d056
to
38ff5e3
Compare
Made some test builds and size comparison: |
Yes, I reached the same numbers. How do you want to continue? |
I think the size difference of the final distributable files is negligible, I'd rather keep numpy. I've done lots of image processing work in the past with numpy and know how useful it is, it may come in handy in the future. I also tested startup times and didn't see any significant difference. (maybe 1 second?) |
I see. Then NumPy version it is. Regarding the algorithm - there are still issues with thin fonts of page numbers and instances of a single-digit page num that the algorithm fails to detect with higher power levels (but less of a problem with lower power levels). As Zhao demonstrated, the algorithm works fine in most cases and I think it is ready for general use, even if more tweaks and improvements are needed for some edge cases or maybe some scenarios that I haven't tested yet. What about the issue I have with the inconsistency with power levels of the current "crop margins" versus the new "crop margin + page num"? @zhaohengkang Very nice comparison images you compiled there! seems like you worked hard sharing these results! |
@neyney10 Sorry, because when I turned it on, the default was power=2, and precisely this power met my requirements, so I did not use the lower power to test. |
Sorry, totally forgot you asked a question here. Is it easy to modify the existing modify "crop margins" algorithm? And is it unlikely to cause issues for users? If so, do it. Otherwise, just put a note in the tooltip that the power is used differently. If you really want to offer the old behavior too, you can add a LEGACY checkbox. |
Summary
Motivation
E-reader screen real estate is an important resource.
More available screen size means more details can be better seen, especially text.
Text is one of the most important elements that need to be clearly readable on e-readers,
which mostly are smaller devices where the need to zoom is unwanted.
By cropping the page number on the bottom of the page, 2%-5% of the page height can be regained
that allows us to upscale the image even more.
The Current Algorithm Fails
While it is possible to adjust the 'power' of the cropping, I can only gain some success when the power is at least 4 (using the power user EXE), where the GUI itself only allows up to 2.
The current algorithm fails in all of the cases that I have at hand.
A Better Algorithm
I wrote a Python function using PIL, NumPy (openCV might perform faster, but I regressed to PIL as it exists as a dependency already and including OpenCV is heavy, package weight-wise).
OUTPUT EXAMPLES OF THE NEW ALGORITHM
(I extended the power level limit to 3, from the previous limit of 2)
Page Number Cropping
Showcasing Its Ability To Retain Manga Content
It does not crop the page number if it detects other things that might be cropped along with the page number.
Issues