Open vatavian opened 3 months ago
Instead of replacing the original image src, we can duplicate it, change the src, then set display: none, on the original. This will not render the element at all, solving the memory issue, while keeping the original's code. The duplicate tag would probably also behave the same way and get destroyed when the original does. We can then just swap between the original and colored by toggling the display property, by maybe just clicking on the image? or onclick hold? Or since force-color would require a button anyway, we can just put these in right click context menu?
At the moment, when I visit mangadex.org
and if "Long Strip" is ON during processing images by MC, my computer starts to die due to RAM runs out.
I don't know how it will be if the original image sources are duplicated.
Done the show-original feature, highly optimized, please test and let me know if it's ok.
Excellent! Thank you so much!
PS. As you can see, page#3 https://mangadex.org/chapter/27b6de48-beac-4821-a736-4f46e4372717/3 is not being recognized by MC as a bw-image.
MangaColorizer-show-orig-images-Video_2024-07-31_21-20-06_2.webm
The linked example has bright yellow in some of the lettering at the top. That makes it not look like a black-and-white or grayscale image. Maybe it sometimes misses the colored parts if stride is large enough, but if it notices any of those yellow pixels it will think the image is already colored. I did a quick search for algorithms others have used, but didn't find a good one yet.
The following project recognizes this image as a grayscale image and processes it properly. https://github.com/xiaogdgenuine/Manga-Colorization-FJ/blob/2aa20d45742ae742830264984b39a79ef2a530c0/inference.py#L11
I really don't think the algorithm is the problem, it's getting colorized for me. The max distance from gray shows 2 in the console logs, much less than the default tolerance of 30. Is this happening every time for you?
Does the donation page (https://mangadex.org/chapter/27b6de48-beac-4821-a736-4f46e4372717/17) get colorized by MC-FJ?
My parameters were the following:
Color Tolerance = 30
Color Stride = 4
And with such parameters I got the aforementioned results.
Changing Color Stride
to 2
leads to colorization of page#3, but with it also starts processing and colorizing images that are already in color.
https://mangadex.org/chapter/27b6de48-beac-4821-a736-4f46e4372717/18
https://mangadex.org/chapter/27b6de48-beac-4821-a736-4f46e4372717/17
Does the donation page (https://mangadex.org/chapter/27b6de48-beac-4821-a736-4f46e4372717/17) get colorized by MC-FJ?
No, it doesn't.
Also, there is issue with senkuro.com
, when Reading Mode
is set to Vertical
.
Starting from page 4-5, it's not the manga images that are being colorized, but the website placeholders.
https://senkuro.com/manga/re-monster/chapters/119429828913939988/pages/1
MangaColorizer-reMonter-vertical-issue-Video_2024-08-01_00-25-14.webm
After updating the grayscale algorithm, an issue with no image processing on senkuro.com
appeared.
MangaColorizer-senkuro-not-processed-Video_2024-08-01_17-24-37.webm
Yes, that was an untested update, try it now.
Thanks! Now it works with the one-page layout on senkuro.com
, but when using the "Vertical" layout it still colorizes placeholders with red big dots.
Yes, it will do that, but should automatically re-correct almost instantly. Can break maybe if images loading too fast, I'll fix.
https://drive.google.com/file/d/13NFE6qblCgc3p8q89StkIm_u5MEWslQd/view
Fixed 👍
It works! Thank you very much!
Sometimes it would be nice to easily show the original image. Maybe the coloring made some text hard to read or you are just curious to see how it looked before coloring. This could be done in a number of ways. The first few I can think of are:
I want to be sure the regular reading experience is not cluttered with any new visible buttons in the page. Even if they only show up on hover, they will often be flickering into view. I was thinking of a right-click menu item to make this happen, but maybe nobody would ever find it and in some browsers that menu is already crowded. Maybe something in the settings popup could enable showing originals.
It will take a little thought about how to implement since we currently discard the original image data and src when it gets colored. There is also a lot of variety in how pages handle images. Some natively keep only a few img elements and create and destroy them as you read, others have one for every image in the chapter but clear the image data of ones that have scrolled by to save memory. Saving all original image data will increase by double (or more) the memory a page takes up while reading, so we may not want to enable it by default.
A related feature would be allowing the user to force coloring of an image that was not originally colored because there is already some color in it. This may end up needing its own separate issue for discussion and implementation, but it may help to think about both as we figure out what to do.