On 2020-11-15 at 06:06, tomas@tuxteam.de wrote: > On Sun, Nov 15, 2020 at 05:27:49AM -0500, The Wanderer wrote: > >> On 2020-11-15 at 04:38, tomas@tuxteam.de wrote: >> >>> On Sun, Nov 15, 2020 at 12:31:22AM +0100, Emanuel Berg wrote: >>> >>>> Hello, is there a tool/command/script anywhere that can >>>> overwrite with a single color (or make transparent) every pixel >>>> to the left, above, right, and below a certain other color? >>>> >>>> e.g., if one draws a loop of black, tell the program black is >>>> the border, the result would be only what is within the loop? > > [...] > >> I think you may have misunderstood the request - either that, or I >> did. >> >> From the description of "flood fill", what it does is replace >> everything within a certain distance of a specified point with a >> specified color. That maps to "fill a specified region with a >> specified color", if the region is radius-based. > > No, no. Unless you mean "distance in colour space". Look again at the > given ref, [0]. > > Flood starts at a pixel, considers every neighbour [1] having the > same colour [2] and repeats that process for those selected > neighbours, until all possibilities are exhausted. Optimising that is > left as an exercise to the reader, as they say :-) > > It's a "classic" in bitmap and pixmap graphics. Ah, right, I'd missed the "color that matches" part of the phrase. That does significantly change the meaning of the definition at that given link, to something which matches much better with what I'd have expected the term to mean in the first place. In that case this seems like an even less suitable match for the request as I parse it. >> What I understand the request to be is for a way to replace >> everything *outside of* a specified region with a specified color, >> where the region is *not* necessarily radius-based but may >> potentially be freeform. > > Yes, but then, one person's "inside" is the other person's > "outside". You just have to choose judiciously your start point (aka > "seed"). And, of course, make sure the region thusly defined is > connected. I either am badly confused, or don't understand how this relates to the request at all. If I'm reading the original request correctly (which I'll admit is by no means guaranteed), the "single color" used to draw the "loop" - i.e., in the example, black - is incidental to the goal; it just defines the boundary of the region which is to be left unchanged. It may or not even be important to retain the colored perimeter line in the result; I'd intuitively expect not, but there could be reasons to do so. What's outside (or, if you prefer, "on the other side of") the boundary may well be thousands of different colors, not necessarily in any pattern which the program can be expected to recognize with relation to another. The important part of the request is wanting to overwrite all of that region outside the boundary - regardless of its initial color - with a single, specified color (for values of "color" that include full transparency). I don't see how "flood fill" can fulfill that at all. My best guess would involve the mention at your given reference link of a "-fuzz" option which lets the color matching be inexact; that could potentially make it possible to have a "define the boundary" color which is sufficiently distinct from every color in the external region that the fill will be able to match and replace all of the latter but will reject and neither replace nor propagate past the former, but it seems improbable that it would be practical to have this distinctness hold true for every image you might want to process this way. (Then again it'd also seem impractical to guarantee that whatever color is chosen for defining the boundary will not occur outside of the boundary; I think that's why I've been mostly assuming that the literal drawing of the boundary with a color is just part of an attempt at a solution to the problem, not an essential part of the problem definition itself.) >> If I needed to do that, what I'd probably wind up doing is to >> select the desired region, copy it, paste it into an empty image, >> and adjust its position and the size of the image to suit. I don't >> know of any tool to automate the process to any meaningful degree. > > Hm. I can't follow that last one. Perhaps I haven't understood > anything, after all (not unheard of, mind you :). Where does the > (re-) positioning come in? It comes in if the relative location of the specified region compared against the edges of the canvas is important. If you stay with just one image (canvas), and replace everything outside the specified region with a specified color, then the relative position of the region remains unchanged. If you copy the region into a new image (canvas), it will be placed wherever the program decides to put it relative to the edges of that new canvas, which may or may not wind up having any similarity to its location on the original canvas. If that relative positioning was important, then one that doesn't match it won't suit, so repositioning would be needed. If it wasn't important, then the new arbitrary positioning would already suit, so no adjustment would be called for. Similarly for the size of the original canvas vs. that of the new, previously-empty image. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature