New feature idea: ability to show original image

[vatavian]

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:

1. Replace the colored version with the original on the page so you only see the original.
2. Try to show both original and colored version side-by-side or vertically.
3. Be able to swap back and forth quickly.
4. Load the whole page in another window or tab without coloring.

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.

[BinitDOX]

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?

[iG8R]

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.

[BinitDOX]

Done the show-original feature, highly optimized, please test and let me know if it's ok.

[iG8R]

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

[vatavian]

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.

[iG8R]

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

[iG8R]

[BinitDOX]

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?

[BinitDOX]

Does the donation page (https://mangadex.org/chapter/27b6de48-beac-4821-a736-4f46e4372717/17) get colorized by MC-FJ?

[iG8R]

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.

[iG8R]

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

[iG8R]

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

[BinitDOX]

Yes, that was an untested update, try it now.

[iG8R]

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.

[BinitDOX]

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

[BinitDOX]

Fixed 👍

[iG8R]

It works! Thank you very much!