<p>I'm trying to figure out how to go about removing the &quot;colorization&quot; of comic/cartoon/manga/etc drawn-art inputs where the black-ink strokes (&quot;the line-art&quot;) are to be retained against (near-perfectly-)white &quot;background&quot; — but also in a smooth non-jagged manner so there'll be some retaining/graying of the &quot;fade tones&quot; from the ink-blacks to the background (formerly colored, now white).</p>
<p>(Note: I'm trying to go here <em><a href="https://aaronhertzmann.com/2020/04/19/lines-as-edges.html#problem-5-edge-detection-is-not-a-line-drawing-algorithm" rel="nofollow noreferrer">without</a> edge-detection or vector-ization or binarization algos</em>, for &quot;merely&quot; a smoother alternative to any &amp; all always-jaggy B/W thresholding (binarization) approaches you'll ever find.)</p>
<p>This colorized input, for example, sports quite dark colorization tones that would still have to turn (near-)<code>#FF</code> for the removing-colorization-but-preserving-the-black-inks use case — despite (in grayscale) being quite close to the original-black-inks-to-be-fully-preserved in the (seemingly ca.) <code>#00..#36</code> range.</p>
<p><a href="https://i.sstatic.net/ALkuc.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ALkuc.jpg" alt="enter image description here" /></a></p>
<p>The problem is likely simplified (though that's just assumption on my part, not a necessary requirement) by first generating a light-greyscale (max-decomposition ie. <code>gray=max(r,g,b)</code>) version to work with:</p>
<p><a href="https://i.sstatic.net/sd5lE.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/sd5lE.png" alt="enter image description here" /></a></p>
<p>Now any given hard-coded threshold cutoff value <code>t</code> (for turning all-grays-above-<code>t</code> into <code>#FF</code>, keeping all-below-<code>t</code> as they are) will not &quot;work&quot; to produce a smooth outcome, to wit for <code>t=#36</code>:</p>
<p><a href="https://i.sstatic.net/DC5ks.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/DC5ks.png" alt="enter image description here" /></a></p>
<p><strong>No matter</strong> one's choice of cutoff threshold <code>t</code>, the result will naturally <strong>always</strong> be jaggy and impoverished (just in different places), with some lines too-severely-thickened, others too harshly thinned or lost, plus dither noise. This goes for hard-coded thresholds or auto-thresholding-computed ones (unless there's one I haven't encountered yet that's especially geared to this scenario — most of them are for lo-fi text-scans or photographs).</p>
<p>What's really needed at these low resolutions is to fade as smoothly into white from the line-blacks as they originally fade into colorization (or grayscaled, into grays).</p>
<p>I guess that there should be <strong>either</strong> some near-perfectly-suited <em>Curve</em> (<code>some 0..1 -&gt; another 0..1</code> I haven't yet found) that would solve this &quot;good enough&quot; (for the human visual perception), <strong>or</strong> perhaps some other papers/algos/research/gfx-techniques tackling this very use-case (albeit in jargon I wouldn't know to include in searches)... thanks for any ideas and pointers!</p>

CC BY-SA 4.0
2022-08-09T02:17:48.020Z
I wonder whether the first step of creating a grayscale image is leading you down a suboptimal path. I'd be tempted to try doing a color separation first, processing the redscale, greenscale, and bluescale images separately, and then merging the results. If that doesn't help, I'd probably start looking for a matrix blur filter or edge detector that can consider more local context than the simple threshold operation does.
luser droog
CC BY-SA 4.0
2022-08-09T07:49:04.443Z
Use a halftoning algorithm such as Floyd-Steinberg or direct binary search. You can also try more advanced algorithms such as the stippling here (see the figures): https://arxiv.org/abs/2206.07798
lightxbulb
CC BY-SA 4.0
2022-08-09T08:05:32.443Z
Thanks @lightxbulb — I should clarify that all "colorization" (aside from the black-ink-strokes aka "outlines") is not to be re-expressed into black-dot arrangements (stippling / half-toning) but "removed wholly" (turned `#ffffff` except for the "subpixel-ish" fade-to-black grey tones for retaining a non-jagged smoothness)
Phil S.
CC BY-SA 4.0
2022-08-09T08:09:23.700Z
Thanks @luserdroog I'm tempted to experiment in that color-sep direction, but I can't quite intuit what I'd do with each separate channel before the final merge?

(Btw. I did one experiment where I determine a pixel's "colorness / non-gray-ness" via the deltas between channels. Idea being, the more "colorish" a pixel, the more it turns into white. Somehow it ended up as a perfectly fine greyscale rather than the truly (perceptually) inks-only non-colorized black-white monochrome that I'm seeking here to "restore" even for fairly lo-res (HD/FHD rather than 4K so to speak) inputs...)
Phil S.
CC BY-SA 4.0
2022-08-09T08:17:50.023Z
Then I am not sure I understand what you are trying to achieve or why you call it colorization. Colorization typically means producing a color image from a greyscale one. "I'm trying to go here" - I guess my question is where is "there"? What do you want to get as a result?
lightxbulb
CC BY-SA 4.0
2022-08-09T08:33:51.210Z
@lightxbulb sorry for any unclear phrasings prior, it's all about "removing the colorization in comic-art images" where the black-ink strokes are to be retained against (near-perfectly-)white "background" --- but also in a smooth non-jagged manner so there'll be some gray tones in the fade from the ink-blacks to the background (formerly colored, now white). Hence binary thresholding is out...
Phil S.
CC BY-SA 4.0
2022-08-09T10:18:43.547Z
You might want to look into the distance transform here is a paper on the subject  https://www.comp.nus.edu.sg/~tants/jfa/i3d06.pdf and here is an implementation https://www.shadertoy.com/view/4syGWK
pmw1234
<algorithm><image-processing><2d><2d-graphics><bitmap-graphics>
Turning colorized comic-art into uncolorized monochrome (line-art-inks-only B&W), not just very-light-grayscale
Phil S.
# Turning colorized comic-art into uncolorized monochrome (line-art-inks-only B&W), not just very-light-grayscale

(Asked by: username_0 on 2022-08-07)

I'm trying to figure out how to go about removing the "colorization" of comic/cartoon/manga/etc drawn-art inputs where the black-ink strokes ("the line-art") are to be retained against (near-perfectly-)white "background" — but also in a smooth non-jagged manner so there'll be some retaining/graying of the "fade tones" from the ink-blacks to the background (formerly colored, now white).

(Note: I'm trying to go here *[without](https://aaronhertzmann.com/2020/04/19/lines-as-edges.html#problem-5-edge-detection-is-not-a-line-drawing-algorithm) edge-detection or vector-ization or binarization algos*, for "merely" a smoother alternative to any & all always-jaggy B/W thresholding (binarization) approaches you'll ever find.)

This colorized input, for example, sports quite dark colorization tones that would still have to turn (near-)`#FF` for the removing-colorization-but-preserving-the-black-inks use case — despite (in grayscale) being quite close to the original-black-inks-to-be-fully-preserved in the (seemingly ca.) `#00..#36` range.

[![enter image description here](https://i.sstatic.net/ALkuc.jpg)](https://i.sstatic.net/ALkuc.jpg)

The problem is likely simplified (though that's just assumption on my part, not a necessary requirement) by first generating a light-greyscale (max-decomposition ie. `gray=max(r,g,b)`) version to work with:

[![enter image description here](https://i.sstatic.net/sd5lE.png)](https://i.sstatic.net/sd5lE.png)

Now any given hard-coded threshold cutoff value `t` (for turning all-grays-above-`t` into `#FF`, keeping all-below-`t` as they are) will not "work" to produce a smooth outcome, to wit for `t=#36`:

[![enter image description here](https://i.sstatic.net/DC5ks.png)](https://i.sstatic.net/DC5ks.png)

**No matter** one's choice of cutoff threshold `t`, the result will naturally **always** be jaggy and impoverished (just in different places), with some lines too-severely-thickened, others too harshly thinned or lost, plus dither noise. This goes for hard-coded thresholds or auto-thresholding-computed ones (unless there's one I haven't encountered yet that's especially geared to this scenario — most of them are for lo-fi text-scans or photographs).

What's really needed at these low resolutions is to fade as smoothly into white from the line-blacks as they originally fade into colorization (or grayscaled, into grays).

I guess that there should be **either** some near-perfectly-suited *Curve* (`some 0..1 -> another 0..1` I haven't yet found) that would solve this "good enough" (for the human visual perception), **or** perhaps some other papers/algos/research/gfx-techniques tackling this very use-case (albeit in jargon I wouldn't know to include in searches)... thanks for any ideas and pointers!

**Tags:** algorithm, image-processing, 2d, 2d-graphics, bitmap-graphics

> **Comments:**
> **username_1**: I wonder whether the first step of creating a grayscale image is leading you down a suboptimal path. I'd be tempted to try doing a color separation first, processing the redscale, greenscale, and bluescale images separately, and then merging the results. If that doesn't help, I'd probably start looking for a matrix blur filter or edge detector that can consider more local context than the simple threshold operation does.  
> **username_2**: Use a halftoning algorithm such as Floyd-Steinberg or direct binary search. You can also try more advanced algorithms such as the stippling here (see the figures): https://arxiv.org/abs/2206.07798  
> **username_0**: Thanks @username_2 — I should clarify that all "colorization" (aside from the black-ink-strokes aka "outlines") is not to be re-expressed into black-dot arrangements (stippling / half-toning) but "removed wholly" (turned `#ffffff` except for the "subpixel-ish" fade-to-black grey tones for retaining a non-jagged smoothness)  
> **username_0**: Thanks @username_1 I'm tempted to experiment in that color-sep direction, but I can't quite intuit what I'd do with each separate channel before the final merge?  (Btw. I did one experiment where I determine a pixel's "colorness / non-gray-ness" via the deltas between channels. Idea being, the more "colorish" a pixel, the more it turns into white. Somehow it ended up as a perfectly fine greyscale rather than the truly (perceptually) inks-only non-colorized black-white monochrome that I'm seeking here to "restore" even for fairly lo-res (HD/FHD rather than 4K so to speak) inputs...)  
> **username_2**: Then I am not sure I understand what you are trying to achieve or why you call it colorization. Colorization typically means producing a color image from a greyscale one. "I'm trying to go here" - I guess my question is where is "there"? What do you want to get as a result?  
> **username_0**: @username_2 sorry for any unclear phrasings prior, it's all about "removing the colorization in comic-art images" where the black-ink strokes are to be retained against (near-perfectly-)white "background" --- but also in a smooth non-jagged manner so there'll be some gray tones in the fade from the ink-blacks to the background (formerly colored, now white). Hence binary thresholding is out...  
> **username_3**: You might want to look into the distance transform here is a paper on the subject  https://www.comp.nus.edu.sg/~tants/jfa/i3d06.pdf and here is an implementation https://www.shadertoy.com/view/4syGWK  

---

## 0 answers

