Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228663 > unrolled thread

color border in image, drop everything outside of it

Back to article view | Back to linux.debian.user

Contents

  color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-15 00:40 +0100
    Re: color border in image, drop everything outside of it Michael uplawski <linux-gate@don.blech.e4ward.com> - 2020-11-15 10:00 +0100
      Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-15 10:10 +0100
        Re: color border in image, drop everything outside of it Michael uplawski <linux-gate@don.blech.e4ward.com> - 2020-11-15 11:10 +0100
          Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-15 11:30 +0100
          Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-22 03:30 +0100
    Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-15 10:40 +0100
      Re: color border in image, drop everything outside of it The Wanderer <wanderer@fastmail.fm> - 2020-11-15 11:30 +0100
        Re: color border in image, drop everything outside of it Jeremy Ardley <jeremy@ardley.org> - 2020-11-15 12:00 +0100
        Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-15 12:10 +0100
          Re: color border in image, drop everything outside of it The Wanderer <wanderer@fastmail.fm> - 2020-11-15 12:50 +0100
            Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-15 13:30 +0100
        Re: color border in image, drop everything outside of it Michael uplawski <linux-gate@don.blech.e4ward.com> - 2020-11-15 12:10 +0100
          Re: color border in image, drop everything outside of it Michael uplawski <linux-gate@don.blech.e4ward.com> - 2020-11-15 12:50 +0100
        Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-22 03:20 +0100
      Re: color border in image, drop everything outside of it mick crane <mick.crane@gmail.com> - 2020-11-15 11:40 +0100
      Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-22 03:20 +0100
        Re: color border in image, drop everything outside of it David Wright <deblis@lionunicorn.co.uk> - 2020-11-22 04:40 +0100
          Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-22 05:20 +0100
            Re: color border in image, drop everything outside of it David Wright <deblis@lionunicorn.co.uk> - 2020-11-23 06:20 +0100
              Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-23 06:30 +0100
                Re: color border in image, drop everything outside of it David Wright <deblis@lionunicorn.co.uk> - 2020-11-24 20:50 +0100
                  Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-24 22:40 +0100
                    Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-24 22:50 +0100
                      Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-26 01:30 +0100
                        Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-26 09:50 +0100
                          Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-26 12:30 +0100
                            Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-26 12:40 +0100
                              Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-26 12:50 +0100
                                Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-26 14:10 +0100
        Re: color border in image, drop everything outside of it <tomas@tuxteam.de> - 2020-11-22 10:10 +0100
          Re: color border in image, drop everything outside of it Emanuel Berg <moasenwood@zoho.eu> - 2020-11-22 10:30 +0100

Page 2 of 2 — ← Prev page 1 [2]

#228937

> I don't understand what you mean by "sensible" data.
> Your example
>
>   .........
>   ...sss...
>   ..skkks..
>   ..sssss..
>   ....ss...
>
> is a completely convex blob. Are we to understand that as
> a constraint? Or are re-entrant shaped loops allowed? What sort
> of re-entrants?

I have described the intention using everyday language.

Then I described the algorithm that would accomplish this.

Finally, I provided this ascii art example.

If that still isn't enough, well, you know what they say, it ain't
worth it explaining to someone who doesn't understand.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#229031

[Multipart message — attachments visible in raw view] — view raw

On Mon 23 Nov 2020 at 06:23:50 (+0100), Emanuel Berg wrote:
> > I don't understand what you mean by "sensible" data.
> > Your example
> >
> >   .........
> >   ...sss...
> >   ..skkks..
> >   ..sssss..
> >   ....ss...
> >
> > is a completely convex blob. Are we to understand that as
> > a constraint? Or are re-entrant shaped loops allowed? What sort
> > of re-entrants?
> 
> I have described the intention using everyday language.
> 
> Then I described the algorithm that would accomplish this.
> 
> Finally, I provided this ascii art example.
> 
> If that still isn't enough, well, you know what they say, it ain't
> worth it explaining to someone who doesn't understand.

Fair enough, but I thought you were worth explaining it to, so here
goes with some ascii art. I started with a larger image than yours at
https://lists.debian.org/debian-user/2020/11/msg00496.html
but using the same notation, and I carried out your algorithm at
https://lists.debian.org/debian-user/2020/11/msg00494.html
but showing my working by leaving arrows as the scan passed.

The first pass is simple, with 'd' turning into →. In the second
pass, I've only shown ↓ where there was still a 'd' to be dropped,
so there aren't any ↓ marks down the lefthand side or along the
top, as those have already been dropped. (If you're unconvinced,
a 'trampling' version is attached.)

Similarly for the third and fourth passes. This last scan does
nothing of course because it either scans up over points already
dropped, or hits an 's' and stops.

As you can see, there are several 'd's left at the end of all four
scans, which your algorithm misses because the 's' loop stopped
the scan from reaching them.

    Original                     Scanned

ddddddddddddddddddddddddd    →→→→→→→→→→→→→→→→→→→→→→→→→
ddddddddddddddddddddddddd    →→→→→→→→→→→→→→→→→→→→→→→→→
ddddsssssssssssssssssdddd    →→→→sssssssssssssssss↓↓↓↓
ddddskkkkkkkkkkkkkkksdddd    →→→→skkkkkkkkkkkkkkks↓↓↓↓
ddddskkkkkkkkkkkkkkksdddd    →→→→skkkkkkkkkkkkkkks↓↓↓↓
ddddskkkkkkkssssskkksdddd    →→→→skkkkkkkssssskkks↓↓↓↓
ddddskkkkkkksddddskksdddd    →→→→skkkkkkksddddskks↓↓↓↓
ddddskkkkkkksdddddsssdddd    →→→→skkkkkkksdddddsss↓↓↓↓
ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
dddddskkkkkkksddddddddddd    →→→→→skkkkkkks←←←←←←←↓↓↓↓
ddddddskkkkkkksdddddddddd    →→→→→→skkkkkkks←←←←←←↓↓↓↓
dddddddskkkkkkksddddddddd    →→→→→→→skkkkkkks←←←←←↓↓↓↓
ddddddskkkkkkkkksdddddddd    →→→→→→skkkkkkkkks←←←←↓↓↓↓
dddddskkkkkkkkkkksddddddd    →→→→→skkkkkkkkkkks←←←↓↓↓↓
ddddskkkkkkkkkkkkksdddddd    →→→→skkkkkkkkkkkkks←←↓↓↓↓
ddddssssssssssssssssddddd    →→→→ssssssssssssssss←↓↓↓↓
ddddddddddddddddddddddddd    →→→→→→→→→→→→→→→→→→→→→→→→→
ddddddddddddddddddddddddd    →→→→→→→→→→→→→→→→→→→→→→→→→

    Achieved                     Desired

.........................    .........................
.........................    .........................
....sssssssssssssssss....    ....sssssssssssssssss....
....skkkkkkkkkkkkkkks....    ....skkkkkkkkkkkkkkks....
....skkkkkkkkkkkkkkks....    ....skkkkkkkkkkkkkkks....
....skkkkkkkssssskkks....    ....skkkkkkkssssskkks....
....skkkkkkksddddskks....    ....skkkkkkks....skks....
....skkkkkkksdddddsss....    ....skkkkkkks.....sss....
....skkkkkkks............    ....skkkkkkks............
....skkkkkkks............    ....skkkkkkks............
....skkkkkkks............    ....skkkkkkks............
....skkkkkkks............    ....skkkkkkks............
....skkkkkkks............    ....skkkkkkks............
.....skkkkkkks...........    .....skkkkkkks...........
......skkkkkkks..........    ......skkkkkkks..........
.......skkkkkkks.........    .......skkkkkkks.........
......skkkkkkkkks........    ......skkkkkkkkks........
.....skkkkkkkkkkks.......    .....skkkkkkkkkkks.......
....skkkkkkkkkkkkks......    ....skkkkkkkkkkkkks......
....ssssssssssssssss.....    ....ssssssssssssssss.....
.........................    .........................
.........................    .........................

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#229040

David Wright wrote:

>     Original                     Scanned
>
> ddddddddddddddddddddddddd    →→→→→→→→→→→→→→→→→→→→→→→→→
> ddddddddddddddddddddddddd    →→→→→→→→→→→→→→→→→→→→→→→→→
> ddddsssssssssssssssssdddd    →→→→sssssssssssssssss↓↓↓↓
> ddddskkkkkkkkkkkkkkksdddd    →→→→skkkkkkkkkkkkkkks↓↓↓↓
> ddddskkkkkkkkkkkkkkksdddd    →→→→skkkkkkkkkkkkkkks↓↓↓↓
> ddddskkkkkkkssssskkksdddd    →→→→skkkkkkkssssskkks↓↓↓↓
> ddddskkkkkkksddddskksdddd    →→→→skkkkkkksddddskks↓↓↓↓
> ddddskkkkkkksdddddsssdddd    →→→→skkkkkkksdddddsss↓↓↓↓
> ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
> ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
> ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
> ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
> ddddskkkkkkksdddddddddddd    →→→→skkkkkkks←←←←←←←←↓↓↓↓
> dddddskkkkkkksddddddddddd    →→→→→skkkkkkks←←←←←←←↓↓↓↓
> ddddddskkkkkkksdddddddddd    →→→→→→skkkkkkks←←←←←←↓↓↓↓
> dddddddskkkkkkksddddddddd    →→→→→→→skkkkkkks←←←←←↓↓↓↓
> ddddddskkkkkkkkksdddddddd    →→→→→→skkkkkkkkks←←←←↓↓↓↓
> dddddskkkkkkkkkkksddddddd    →→→→→skkkkkkkkkkks←←←↓↓↓↓
> ddddskkkkkkkkkkkkksdddddd    →→→→skkkkkkkkkkkkks←←↓↓↓↓
> ddddssssssssssssssssddddd    →→→→ssssssssssssssss←↓↓↓↓
> ddddddddddddddddddddddddd    →→→→→→→→→→→→→→→→→→→→→→→→→
> ddddddddddddddddddddddddd    →→→→→→→→→→→→→→→→→→→→→→→→→
>
>     Achieved                     Desired
>
> .........................    .........................
> .........................    .........................
> ....sssssssssssssssss....    ....sssssssssssssssss....
> ....skkkkkkkkkkkkkkks....    ....skkkkkkkkkkkkkkks....
> ....skkkkkkkkkkkkkkks....    ....skkkkkkkkkkkkkkks....
> ....skkkkkkkssssskkks....    ....skkkkkkkssssskkks....
> ....skkkkkkksddddskks....    ....skkkkkkks....skks....
> ....skkkkkkksdddddsss....    ....skkkkkkks.....sss....
> ....skkkkkkks............    ....skkkkkkks............
> ....skkkkkkks............    ....skkkkkkks............
> ....skkkkkkks............    ....skkkkkkks............
> ....skkkkkkks............    ....skkkkkkks............
> ....skkkkkkks............    ....skkkkkkks............
> .....skkkkkkks...........    .....skkkkkkks...........
> ......skkkkkkks..........    ......skkkkkkks..........
> .......skkkkkkks.........    .......skkkkkkks.........
> ......skkkkkkkkks........    ......skkkkkkkkks........
> .....skkkkkkkkkkks.......    .....skkkkkkkkkkks.......
> ....skkkkkkkkkkkkks......    ....skkkkkkkkkkkkks......
> ....ssssssssssssssss.....    ....ssssssssssssssss.....
> .........................    .........................
> .........................    .........................

OK, nice work, good point!

Well, you have to extent the algorithm so that when it hits a dead
end, it doesn't stop, instead it tries the other directions.

Or maybe do it like this: just rush forward until you hit
something. When you do, proceed around it as tightly as possible
until you reach the original position!

BTW maybe the AI people already have a true and tested algorithm
for this problem?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#229041

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 24, 2020 at 10:39:08PM +0100, Emanuel Berg wrote:

[...]

> BTW maybe the AI people already have a true and tested algorithm
> for this problem?

I repeat myself. It is a variant of flood fill [1]. AI not needed.
Classical raster computer graphics stuff.

Cheers

[1] https://en.wikipedia.org/wiki/Flood_fill

 - t

[toc] | [prev] | [next] | [standalone]

#229092

tomas wrote:

>> BTW maybe the AI people already have a true and tested
>> algorithm for this problem?
>
> I repeat myself. It is a variant of flood fill. AI not needed.
> Classical raster computer graphics stuff.

Well, AI or not, I remember the old graphics program (e.g.,
MacPaint) did this all the time. Filled inner and outer regions.
But these regions were uniform, that's the difference...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#229102

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 26, 2020 at 01:22:51AM +0100, Emanuel Berg wrote:
> tomas wrote:
> 
> >> BTW maybe the AI people already have a true and tested
> >> algorithm for this problem?
> >
> > I repeat myself. It is a variant of flood fill. AI not needed.
> > Classical raster computer graphics stuff.
> 
> Well, AI or not, I remember the old graphics program (e.g.,
> MacPaint) did this all the time. Filled inner and outer regions.
> But these regions were uniform, that's the difference...

You don't listen. You don't follow the links. This way, we'll
run in loops (pun intended) for the rests of our lives (luckily
mine is about 3/4 done).

If the regions were uniform, we are talking straight, classical
flood fill, something you would have found out yourself by a
short look at the Wikipedia article I referenced in my last
mail.

The non-uniform case is why I was talking about a "variation"
of the flood fill algorithm. When programming it yourself,
you'd to tweak your comparison operator appropriately. When
doing it as a ImageMagick pipeline, you'd have to make "your"
region uniform first, à la

  convert <yourfile> -fuzz 10% -fill white -opaque <yourloopcolour> <yourfile.out>

or something. Then flood fill. Then use that as mask for your
original.

I'm not going to fill in the details. Gotta cook now.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#229112

tomas wrote:

> I'm not going to fill in the details.

Well, in computing, the details are everything.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#229113

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 26, 2020 at 12:24:40PM +0100, Emanuel Berg wrote:
> tomas wrote:
> 
> > I'm not going to fill in the details.
> 
> Well, in computing, the details are everything.

Yes, that's it -- and they are usually left... to the reader :)

Why should I deprive you of your fun?

Actually it's that my stack is too high: I just wanted to help
you avoid barking up too many wrong trees; in this long thread
I've already seen you & Andrey trying to develop (erroneous)
variants of flood fill. If you have fun in it, I won't spoil
that any longer.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#229114

tomas wrote:

>> Well, in computing, the details are everything.
>
> Yes, that's it -- and they are usually left... to the reader :)
>
> Why should I deprive you of your fun?
>
> Actually it's that my stack is too high: I just wanted to help
> you avoid barking up too many wrong trees; in this long thread
> I've already seen you & Andrey trying to develop (erroneous)
> variants of flood fill. If you have fun in it, I won't spoil
> that any longer.

OK, but one step at a time then!

How do you/what do you use to do this

for pixel (x y) in image; do
  if (pixel.color == BLACK) { pixel.color = GREEN }
done

(made up syntax)

?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

[toc] | [prev] | [next] | [standalone]

#229116

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 26, 2020 at 12:47:12PM +0100, Emanuel Berg wrote:
> tomas wrote:
> 
> >> Well, in computing, the details are everything.
> >
> > Yes, that's it -- and they are usually left... to the reader :)
> >
> > Why should I deprive you of your fun?
> >
> > Actually it's that my stack is too high: I just wanted to help
> > you avoid barking up too many wrong trees; in this long thread
> > I've already seen you & Andrey trying to develop (erroneous)
> > variants of flood fill. If you have fun in it, I won't spoil
> > that any longer.
> 
> OK, but one step at a time then!
> 
> How do you/what do you use to do this
> 
> for pixel (x y) in image; do
>   if (pixel.color == BLACK) { pixel.color = GREEN }
> done
> 
> (made up syntax)

That will strongly depend on what tool/environment
you use. And what BLACK actually means to you. Is
it rgb(0,0,0), or does rgb(1,3,2) [I'm assuming colour
values go between 0..255] also count as black?

If it's the Magick suite we are talking about, try
to make this experiment:

 - download this little guy over there [1]
 - do convert Western_Yellow_Robin_-_10486947383.jpg -fuzz 10% -fill black -opaque "#a0b0e0" robin.jpg
 - watch the results (now in robin.jpg)
 - play with different values of -fuzz

How did I arrive at this '#a0b0e0'? Well, I took some
point in the sky and looked at its colour.

Hint: changing "-opaque <foo>" to "+opaque <foo>" will invert
the effect, i.e. colours /other/ than <foo> (whithin the fuzz
margin) will be overpainted with -fill. This might be more
useful in your use case.

In the end, you'll probably have to do a couple of steps [0]:

 - paint every colour in your image /not equal/ to your
   loop's colour (let's assume light grey, #d3d3d3: you
   /know/ which is your loop's colour, dont you?) in some
   othe colour, say black. If you know your loop's precise
   colour, you won't need a fuzz here.

 - flood fill (yes, here's where flood fill enters the
   -uh- picture) your loop's inner hole (you have some coords
   of your loop's inner hole, don't you) with some /third/
   colour, say white.

 - use that image, stating white as your non-opaque colour
   to set your original's image's alpha channel [2] (i.e.
   you use your transformed image from step 2 as a mask
   or "cookie cutter" to cut out your region of interest).

You'll need some experimenting to get it right. But you'll need
some experimenting anyway to get an idea of what are the aspects
of your problem, and of when it is a meaningful problem and when
it is ill-posed.

Ill-posed in the sense of:

Where does this "gray loop" come from? Have you (electronically)
painted it by hand? Then you might consider cutting the loop
and learning about your tool's selection options.

Does this loop come from a "photo"? Then its colour might not
be as uniform as you would wish (your perception does tricks
on you: you know that, don't you? The loop looks to you as
a "perfect gray loop with no gaps, and nobody else in the
image has this gray colour", but that's the result of some
magic and wonderful image processing in your visual cortex).

And so on.

The only way of getting a feeling for such things is playing
around.

So perhaps some quality time with the Gimp or Krita is the
better approach for you. Magick is great once you /know/ what
you are doing to script a process.

Cheers

[0] Variations are possible depending of whether you want
   the gray loop itself to be part of the final image or
   not. You might be able to skip intermediate steps if
   there were a "flood fill everything /different/ from
   this-and-this colour, but to my knowledge there isn't;
   you might try to hack Magick's source, though).
[1] https://upload.wikimedia.org/wikipedia/commons/4/4b/Western_Yellow_Robin_-_10486947383.jpg
[2] https://imagemagick.org/Usage/compose/#copyopacity

 - t

[toc] | [prev] | [next] | [standalone]

#228905

[Multipart message — attachments visible in raw view] — view raw

On Sun, Nov 22, 2020 at 03:11:21AM +0100, Emanuel Berg wrote:

[...]

> start at (0, 0) - this is the top-left pixel, as you know - is
> this color gray? answer: no. go to (1, 0) etc until you get to
> a grey pixel. at that point, discard all pixels until then.
> and don't look any further to the right on that row!
> 
> do this for all rows from left to right, top to bottom.
> 
> after that, do the same but search top down instead, so after (0,
> 0), go to (0, 1). discard pixels vertically upon gray. and stop.
> 
> do the same from right to left and bottom to top!
> 
> Encirclement!

You are (nearly) describing flood fill. Except that the operator
is ≠ instead of = or, perhaps you have two phases, one with
"≠ grey" and then one with "= grey" to also eliminate the doodle.

I really, strongly suggest you play around with ImageMagick and
"connected component labeling". Here[1]'s the ref, in case it
got lost in the intratubes.

Cheers

[1] https://imagemagick.org/script/connected-components.php

 - t

[toc] | [prev] | [next] | [standalone]

#228906

tomas wrote:

> You are (nearly) describing flood fill. Except that the operator
> is ≠ instead of = or, perhaps you have two phases, one with "≠
> grey" and then one with "= grey" to also eliminate the doodle.
>
> I really, strongly suggest you play around with ImageMagick and
> "connected component labeling". Here[1]'s the ref, in case it
> got lost in the intratubes.

That must be something else? Seems much more complicated. I don't
understand the commands and they seem to do something else.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web