Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #383647 > unrolled thread
| Started by | fir <fir@grunge.pl> |
|---|---|
| First post | 2024-03-16 05:11 +0100 |
| Last post | 2024-05-15 09:57 -0700 |
| Articles | 20 on this page of 167 — 16 participants |
Back to article view | Back to comp.lang.c
filling area by color atack safety fir <fir@grunge.pl> - 2024-03-16 05:11 +0100
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-16 11:33 +0000
Re: filling area by color atack safety Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-16 13:55 +0000
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-16 14:41 +0000
Re: filling area by color atack safety Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-17 10:42 +0000
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 03:00 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-18 14:23 +0200
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 14:13 -0700
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-19 16:05 +0100
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-19 17:16 +0000
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-19 17:33 +0000
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-19 23:07 +0100
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-20 09:29 +0100
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 03:04 -0700
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-16 14:45 +0000
Re: filling area by color atack safety scott@slp53.sl.home (Scott Lurndal) - 2024-03-16 18:21 +0000
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-16 20:02 +0000
Re: filling area by color atack safety "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-16 13:29 -0700
Re: filling area by color atack safety "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-17 13:19 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-18 14:40 +0200
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-19 23:23 +0100
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-17 15:32 +0200
Re: filling area by color atack safety Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-17 11:25 +0000
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-17 12:37 +0000
Re: filling area by color atack safety Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-17 17:11 +0000
Re: filling area by color atack safety Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-23 00:21 +0000
Re: filling area by color atack safety scott@slp53.sl.home (Scott Lurndal) - 2024-03-23 14:43 +0000
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-23 11:48 -0700
Re: filling area by color atack safety scott@slp53.sl.home (Scott Lurndal) - 2024-03-24 20:48 +0000
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-28 22:51 -0700
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-16 15:40 +0100
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-16 15:09 +0000
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-17 14:56 +0000
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-17 17:42 +0200
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-17 18:25 +0200
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-17 19:39 +0200
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 11:36 -0700
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-18 18:51 +0000
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 23:10 -0700
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-19 12:06 +0000
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 00:03 +0100
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-20 01:17 +0200
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 00:30 +0100
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-20 12:06 +0200
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 13:44 +0100
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-20 15:44 +0200
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 15:17 +0100
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 02:15 +0100
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-17 17:45 +0100
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-17 18:28 +0000
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-18 07:58 +0100
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-18 09:26 +0000
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-18 17:28 +0100
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-18 17:25 +0000
Re: filling area by color atack safety scott@slp53.sl.home (Scott Lurndal) - 2024-03-18 17:42 +0000
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-18 18:50 +0000
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-19 11:41 +0100
Re: filling area by color atack safety Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-19 12:19 +0000
Re: filling area by color atack safety Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-18 11:10 -0700
Keith-world (Was: filling area by color atack safety) gazelle@shell.xmission.com (Kenny McCormack) - 2024-03-18 22:42 +0000
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-19 12:31 +0100
Re: filling area by color atack safety "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-18 16:18 -0700
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-19 11:32 +0100
Re: filling area by color atack safety scott@slp53.sl.home (Scott Lurndal) - 2024-03-16 18:25 +0000
Re: filling area by color atack safety Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-17 10:31 +0000
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-17 12:28 +0000
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-17 12:49 +0000
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-17 17:59 +0100
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-19 23:52 +0100
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 01:36 +0100
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-17 14:46 +0200
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-17 12:54 +0000
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-17 15:15 +0200
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-17 13:23 +0000
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-17 15:37 +0200
Re: filling area by color atack safety David Brown <david.brown@hesbynett.no> - 2024-03-17 18:05 +0100
Re: filling area by color atack safety Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-17 14:10 +0000
Re: filling area by color atack safety Spiros Bousbouras <spibou@gmail.com> - 2024-03-17 16:58 +0000
Re: filling area by color atack safety Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-17 22:14 +0000
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-17 22:21 +0000
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 02:30 -0700
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-18 11:08 +0000
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 22:54 -0700
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-19 11:41 +0000
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-19 21:19 -0700
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 01:13 +0100
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-20 10:41 +0200
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 15:20 +0100
Re: filling area by color atack safety Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-03-17 14:27 +0000
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-17 15:13 +0000
Re: filling area by color atack safety Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2024-03-19 10:57 +1100
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 01:26 +0100
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-16 19:13 +0000
Re: filling area by color atack safety bart <bc@freeuk.com> - 2024-03-16 20:23 +0000
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-16 20:29 +0000
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 01:48 +0100
Re: filling area by color atack safety Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2024-03-22 13:04 +1100
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-22 17:55 +0300
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-22 18:31 +0300
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-23 11:06 +0100
Re: filling area by color atack safety Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2024-03-17 18:03 +1100
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 13:09 -0700
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-18 22:42 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-19 13:18 +0200
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-19 11:57 +0000
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-19 15:49 +0200
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-19 21:43 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-20 10:56 +0200
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-20 06:51 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-19 19:18 +0200
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 09:27 +0100
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 09:39 +0100
Re: filling area by color atack safety fir <fir@grunge.pl> - 2024-03-20 09:51 +0100
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-20 07:27 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-24 20:27 +0300
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-24 13:26 -0700
Re: filling area by color atack safety "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-24 14:26 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-25 01:28 +0300
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-26 17:52 +0200
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-30 00:54 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-30 21:26 +0300
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-09 01:00 -0700
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-28 23:04 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-29 15:21 +0200
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-29 23:58 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-30 21:15 +0300
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-31 10:54 +0200
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-09 02:32 -0700
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-09 01:55 -0700
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-30 11:59 -0700
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-20 10:26 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-21 15:36 +0200
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-21 09:47 -0700
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-19 21:40 -0700
Re: filling area by color atack safety "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-19 21:43 -0700
Re: filling area by color atack safety "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-19 21:48 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-20 11:54 +0200
Re: filling area by color atack safety Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-03-20 10:23 +0000
Re: filling area by color atack safety Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-03-20 12:06 +0000
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-20 07:52 -0700
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-20 10:01 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-24 19:33 +0300
Re: filling area by color atack safety Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-24 10:24 -0700
Re: filling area by color atack safety Michael S <already5chosen@yahoo.com> - 2024-03-25 01:04 +0300
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-05 17:30 +0300
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-10 19:47 -0700
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-11 15:20 +0300
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 21:06 -0700
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 21:55 -0700
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 22:09 -0700
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-12 11:13 +0300
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-13 08:30 -0700
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 22:38 -0700
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-11 22:43 -0700
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-12 11:59 -0700
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-13 20:26 +0300
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-13 10:54 -0700
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-13 23:11 +0300
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-17 10:47 -0700
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-17 22:41 +0300
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-19 14:59 -0700
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-20 21:10 +0300
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-04-25 17:56 +0300
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-05-03 18:33 +0300
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-06-05 17:45 +0300
Re: filling area by color atack safety - worst memory size Michael S <already5chosen@yahoo.com> - 2024-06-05 17:59 +0300
Re: filling area by color atack safety - worst memory size Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-15 09:57 -0700
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-03-18 02:30 -0700 |
| Message-ID | <86y1afopik.fsf@linuxsc.com> |
| In reply to | #383685 |
Michael S <already5chosen@yahoo.com> writes:
>> On 16/03/2024 04:11, fir wrote:
>>
>>> i was writing simple editor (something like paint but more custom
>>> for my eventual needs) for big pixel (low resolution) drawing
>>>
>>> it showed in a minute i need a click for changing given drawed area
>>> of of one color into another color (becouse if no someone would
>>> need to do it by hand pixel by pixel and the need to change color
>>> of given element is very common)
>>>
>>> there is very simple method of doing it - i men i click in given
>>> color pixel then replace it by my color and call the same function
>>> on adjacent 4 pixels (only need check if it is in screen at all and
>>> if the color to change is that initial color
>>>
>>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned
>>> old_color, unsigned new_color)
>>> {
>>> if(old_color == new_color) return 0;
>>>
>>> if(XYIsInScreen( x, y))
>>> if(GetPixelUnsafe(x,y)==old_color)
>>> {
>>> SetPixelSafe(x,y,new_color);
>>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>>> return 1;
>>> }
>>>
>>> return 0;
>>> }
[...]
> Except I don't understand why it works it all.
> Can't fill area have sub-areas that only connected through diagonal?
It is customary in raster graphics to count pixels as adjacent
only if they share an edge, not if they just share a corner.
Usually that gives better results; the exceptions tend to need
special handling anyway and not just connecting through
diagonals.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-03-18 11:08 +0000 |
| Message-ID | <ut97c4$4rqf$1@dont-email.me> |
| In reply to | #383713 |
On 18/03/2024 09:30, Tim Rentsch wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
>>> On 16/03/2024 04:11, fir wrote:
>>>
>>>> i was writing simple editor (something like paint but more custom
>>>> for my eventual needs) for big pixel (low resolution) drawing
>>>>
>>>> it showed in a minute i need a click for changing given drawed area
>>>> of of one color into another color (becouse if no someone would
>>>> need to do it by hand pixel by pixel and the need to change color
>>>> of given element is very common)
>>>>
>>>> there is very simple method of doing it - i men i click in given
>>>> color pixel then replace it by my color and call the same function
>>>> on adjacent 4 pixels (only need check if it is in screen at all and
>>>> if the color to change is that initial color
>>>>
>>>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned
>>>> old_color, unsigned new_color)
>>>> {
>>>> if(old_color == new_color) return 0;
>>>>
>>>> if(XYIsInScreen( x, y))
>>>> if(GetPixelUnsafe(x,y)==old_color)
>>>> {
>>>> SetPixelSafe(x,y,new_color);
>>>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>>>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>>>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>>>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>>>> return 1;
>>>> }
>>>>
>>>> return 0;
>>>> }
>
> [...]
>
>> Except I don't understand why it works it all.
>> Can't fill area have sub-areas that only connected through diagonal?
>
> It is customary in raster graphics to count pixels as adjacent
> only if they share an edge, not if they just share a corner.
> Usually that gives better results; the exceptions tend to need
> special handling anyway and not just connecting through
> diagonals.
>
Though with a binary image, if the foreground is 4-connected, the
background must therefore be 8-connected.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-03-18 22:54 -0700 |
| Message-ID | <861q86ojfm.fsf@linuxsc.com> |
| In reply to | #383716 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On 18/03/2024 09:30, Tim Rentsch wrote: > >> Michael S <already5chosen@yahoo.com> writes: [...] >>> Except I don't understand why it works it all. >>> Can't fill area have sub-areas that only connected through >>> diagonal? >> >> It is customary in raster graphics to count pixels as adjacent >> only if they share an edge, not if they just share a corner. >> Usually that gives better results; the exceptions tend to need >> special handling anyway and not just connecting through >> diagonals. > > Though with a binary image, if the foreground is 4-connected, the > background must therefore be 8-connected. It might be but it doesn't have to be. Also different terminology should be used, since 4-connected (also N-connected, for other integer N) has a specific meaning in graph theory, and one very different than what is meant above.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-03-19 11:41 +0000 |
| Message-ID | <utbtlp$q5hs$1@dont-email.me> |
| In reply to | #383733 |
On 19/03/2024 05:54, Tim Rentsch wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On 18/03/2024 09:30, Tim Rentsch wrote: >> >>> Michael S <already5chosen@yahoo.com> writes: > [...] >>>> Except I don't understand why it works it all. >>>> Can't fill area have sub-areas that only connected through >>>> diagonal? >>> >>> It is customary in raster graphics to count pixels as adjacent >>> only if they share an edge, not if they just share a corner. >>> Usually that gives better results; the exceptions tend to need >>> special handling anyway and not just connecting through >>> diagonals. >> >> Though with a binary image, if the foreground is 4-connected, the >> background must therefore be 8-connected. > > It might be but it doesn't have to be. > > Also different terminology should be used, since 4-connected > (also N-connected, for other integer N) has a specific meaning in > graph theory, and one very different than what is meant above. That is the terminology in binary image processing. The pixels are 4-connected or 8-connected depending on whether a shared corner is considered to make the group of pixels two objects or one object. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-03-19 21:19 -0700 |
| Message-ID | <86sf0lmt6g.fsf@linuxsc.com> |
| In reply to | #383739 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On 19/03/2024 05:54, Tim Rentsch wrote: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >>> On 18/03/2024 09:30, Tim Rentsch wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >> >> [...] >> >>>>> Except I don't understand why it works it all. >>>>> Can't fill area have sub-areas that only connected through >>>>> diagonal? >>>> >>>> It is customary in raster graphics to count pixels as adjacent >>>> only if they share an edge, not if they just share a corner. >>>> Usually that gives better results; the exceptions tend to need >>>> special handling anyway and not just connecting through >>>> diagonals. >>> >>> Though with a binary image, if the foreground is 4-connected, the >>> background must therefore be 8-connected. >> >> It might be but it doesn't have to be. >> >> Also different terminology should be used, since 4-connected >> (also N-connected, for other integer N) has a specific meaning in >> graph theory, and one very different than what is meant above. > > That is the terminology in binary image processing. The pixels are > 4-connected or 8-connected depending on whether a shared corner is > considered to make the group of pixels two objects or one object. A poor choice of terminology. Side adjacent or corner and side adjacent would be better.
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-03-20 01:13 +0100 |
| Message-ID | <utd9m5$2eb2n$1@i2pn2.org> |
| In reply to | #383685 |
Michael S wrote:
> On Sat, 16 Mar 2024 11:33:20 +0000
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>
>> On 16/03/2024 04:11, fir wrote:
>>> i was writing simple editor (something like paint but more custom
>>> for my eventual needs) for big pixel (low resolution) drawing
>>>
>>> it showed in a minute i need a click for changing given drawed area
>>> of of one color into another color (becouse if no someone would
>>> need to do it by hand pixel by pixel and the need to change color
>>> of given element is very common)
>>>
>>> there is very simple method of doing it - i men i click in given
>>> color pixel then replace it by my color and call the same function
>>> on adjacent 4 pixels (only need check if it is in screen at all and
>>> if the color to change is that initial color
>>>
>>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned
>>> old_color, unsigned new_color)
>>> {
>>> if(old_color == new_color) return 0;
>>>
>>> if(XYIsInScreen( x, y))
>>> if(GetPixelUnsafe(x,y)==old_color)
>>> {
>>> SetPixelSafe(x,y,new_color);
>>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>>> return 1;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> it work but im not quite sure how to estimate the safety of this -
>>> incidentally as i said i use this editor to low res graphics like
>>> 200x200 pixels or less, and it is only a toll of private use,
>>> yet i got no time to work on it more than 1-2-3 days i guess but
>>> still
>>>
>>> is there maybe simple way to improve it?
>> >
>> This is a cheap and cheerful fllod fill. And it's easy to get right
>> and shouldn't afall over.
>
> Except I don't understand why it works it all.
> Can't fill area have sub-areas that only connected through diagonal?
>
>
this is right remark..i simply not thought on it..but thiose are kinda
details i just my modify the function if i would notice i need the
diagonally conected
note how the topic was born : i was writing the editor, the simple
editor is a work of 1-2 days of code - in here the "recolorisation
of selected (by mouse click) area" is a 30 minutes try then i go further
i asked the topic here as i felt i got no time to rethink if it will
blow my progranm or not but that 30 minurtes task was for 30 minutes
not for a multi hour discusion
hovever i often like to post that some piece of coding to turn into
multi-hpour discusiion to get a bigger ground on some things then coding
become more solid
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-20 10:41 +0200 |
| Message-ID | <20240320104155.00005b24@yahoo.com> |
| In reply to | #383757 |
On Wed, 20 Mar 2024 01:13:10 +0100 fir <fir@grunge.pl> wrote: > > i asked the topic here as i felt i got no time to rethink if it will > blow my progranm or not but that 30 minurtes task was for 30 minutes > not for a multi hour discusion > So you got the answer rather quickly and the answer is: "Yes, in the worst case it can consume a lot of stack. Don't use this simple and elegant algorithm unless you have full control both on size of the images and on size of the stack and on size of the stack frame generates by compiler for each recursive call."
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-03-20 15:20 +0100 |
| Message-ID | <uterbi$2g6te$2@i2pn2.org> |
| In reply to | #383770 |
Michael S wrote: > On Wed, 20 Mar 2024 01:13:10 +0100 > fir <fir@grunge.pl> wrote: >> >> i asked the topic here as i felt i got no time to rethink if it will >> blow my progranm or not but that 30 minurtes task was for 30 minutes >> not for a multi hour discusion >> > > So you got the answer rather quickly and the answer is: > "Yes, in the worst case it can consume a lot of stack. Don't use this > simple and elegant algorithm unless you have full control both on size > of the images and on size of the stack and on size of the stack frame > generates by compiler for each recursive call." > > ye, may conclusion would here be rather put stack to 100 or even 150 MB and forget... then worry if the code (of recolorisation) work too slow (i know howewer this is potential bug af is someone would want then recolorise of very big area there still would be stack overflow, but this is unlikely)
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2024-03-17 14:27 +0000 |
| Message-ID | <ut6ul9$3gr73$1@dont-email.me> |
| In reply to | #383648 |
On Sat, 16 Mar 2024 11:33:20 +0000, Malcolm McLean wrote:
> On 16/03/2024 04:11, fir wrote:
>> i was writing simple editor (something like paint but more custom for my
>> eventual needs) for big pixel (low resolution) drawing
>>
>> it showed in a minute i need a click for changing given drawed area of
>> of one color into another color (becouse if no someone would need to do
>> it by hand pixel by pixel and the need to change color of given element
>> is very common)
>>
>> there is very simple method of doing it - i men i click in given color
>> pixel then replace it by my color and call the same function on adjacent
>> 4 pixels (only need check if it is in screen at all and if the color to
>> change is that initial color
>>
>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
>> unsigned new_color)
>> {
>> if(old_color == new_color) return 0;
>>
>> if(XYIsInScreen( x, y))
>> if(GetPixelUnsafe(x,y)==old_color)
>> {
>> SetPixelSafe(x,y,new_color);
>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>> return 1;
>> }
>>
>> return 0;
>> }
>>
>> it work but im not quite sure how to estimate the safety of this -
>> incidentally as i said i use this editor to low res graphics like
>> 200x200 pixels or less, and it is only a toll of private use,
>> yet i got no time to work on it more than 1-2-3 days i guess but still
>>
>> is there maybe simple way to improve it?
> >
> This is a cheap and cheerful fllod fill. And it's easy to get right and
> shouldn't afall over. But but makes an awful not of unnecessary calls,
> and on a small system and large image might even blow the stack.
>
> Recursion make programs harder to reason about and prove correct.
I would have said that those unfamiliar with the concept of recursion
have a harder time reasoning about the effects of recursion, or proving
their recursive code correct.
Take fir's example code above; a simple single call to
RecolorizePixelAndAdjacentOnes() will effectively recolour the
origin cell multiple times, because of how the recursion is handled.
As an example:
RecolorizePixelAndAdjacentOnes(0,0,1 2)
will
SetPixelSafe(0,0,2);
then invoke
RecolorizePixelAndAdjacentOnes(1,0,1 2)
which will
SetPixelSafe(1,0,2)
and subsequently invoke
...
RecolorizePixelAndAdjacentOnes(0,0,1 2)
which will
SetPixelSafe(0,0,2);
and then invoke
RecolorizePixelAndAdjacentOnes(1,0,1 2)
etc.
[snip]
--
Lew Pitcher
"In Skills We Trust"
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-03-17 15:13 +0000 |
| Message-ID | <ut71ab$3j1n2$1@dont-email.me> |
| In reply to | #383694 |
On 17/03/2024 14:27, Lew Pitcher wrote:
> On Sat, 16 Mar 2024 11:33:20 +0000, Malcolm McLean wrote:
>
>> On 16/03/2024 04:11, fir wrote:
>>> i was writing simple editor (something like paint but more custom for my
>>> eventual needs) for big pixel (low resolution) drawing
>>>
>>> it showed in a minute i need a click for changing given drawed area of
>>> of one color into another color (becouse if no someone would need to do
>>> it by hand pixel by pixel and the need to change color of given element
>>> is very common)
>>>
>>> there is very simple method of doing it - i men i click in given color
>>> pixel then replace it by my color and call the same function on adjacent
>>> 4 pixels (only need check if it is in screen at all and if the color to
>>> change is that initial color
>>>
>>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
>>> unsigned new_color)
>>> {
>>> if(old_color == new_color) return 0;
>>>
>>> if(XYIsInScreen( x, y))
>>> if(GetPixelUnsafe(x,y)==old_color)
>>> {
>>> SetPixelSafe(x,y,new_color);
>>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>>> return 1;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> it work but im not quite sure how to estimate the safety of this -
>>> incidentally as i said i use this editor to low res graphics like
>>> 200x200 pixels or less, and it is only a toll of private use,
>>> yet i got no time to work on it more than 1-2-3 days i guess but still
>>>
>>> is there maybe simple way to improve it?
>> >
>> This is a cheap and cheerful fllod fill. And it's easy to get right and
>> shouldn't afall over. But but makes an awful not of unnecessary calls,
>> and on a small system and large image might even blow the stack.
>>
>> Recursion make programs harder to reason about and prove correct.
>
> I would have said that those unfamiliar with the concept of recursion
> have a harder time reasoning about the effects of recursion, or proving
> their recursive code correct.
>
> Take fir's example code above; a simple single call to
> RecolorizePixelAndAdjacentOnes() will effectively recolour the
> origin cell multiple times, because of how the recursion is handled.
I don't think so. It may look at the original cell, but it will only
recolour it (and recursively process its neighbours) if the colour
hasn't yet changed to the new one.
If I take a 100x100 image with 10,000 cells, which all have to be filled
to the new colour, then SetPixelSafe is called exactly 10,000 times.
The problem is that most of the work is done along a 10,000-deep chain
of nested calls.
[toc] | [prev] | [next] | [standalone]
| From | Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> |
|---|---|
| Date | 2024-03-19 10:57 +1100 |
| Message-ID | <311nck-im1.ln1@hendrix.foo> |
| In reply to | #383694 |
Groovy hepcat Lew Pitcher was jivin' in comp.lang.c on Mon, 18 Mar 2024
01:27 am. It's a cool scene! Dig it.
>> On 16/03/2024 04:11, fir wrote:
[Snip.]
>>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
>>> unsigned new_color)
>>> {
>>> if(old_color == new_color) return 0;
>>>
>>> if(XYIsInScreen( x, y))
>>> if(GetPixelUnsafe(x,y)==old_color)
>>> {
>>> SetPixelSafe(x,y,new_color);
>>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>>> return 1;
>>> }
>>>
>>> return 0;
>>> }
[Snippity doo dah.]
> Take fir's example code above; a simple single call to
> RecolorizePixelAndAdjacentOnes() will effectively recolour the
> origin cell multiple times, because of how the recursion is handled.
No, I don't think so. You seem to have missed the fact that it checks
the colour of the "current" pixel, and only continues (setting new
colour & recursing) if it is the old colour.
Of course, I'm infering (guessing) the functionality, at least
partially (Unsafe? Safe?), of GetPixelUnsafe() and SetPixelSafe() based
on their names.
[Snip Lew's examples.]
--
----- Dig the NEW and IMPROVED news sig!! -----
-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-03-20 01:26 +0100 |
| Message-ID | <utdaf8$2ec1d$1@i2pn2.org> |
| In reply to | #383743 |
Peter 'Shaggy' Haywood wrote:
> Groovy hepcat Lew Pitcher was jivin' in comp.lang.c on Mon, 18 Mar 2024
> 01:27 am. It's a cool scene! Dig it.
>
>>> On 16/03/2024 04:11, fir wrote:
>
> [Snip.]
>
>>>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
>>>> unsigned new_color)
>>>> {
>>>> if(old_color == new_color) return 0;
>>>>
>>>> if(XYIsInScreen( x, y))
>>>> if(GetPixelUnsafe(x,y)==old_color)
>>>> {
>>>> SetPixelSafe(x,y,new_color);
>>>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>>>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>>>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>>>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>>>> return 1;
>>>> }
>>>>
>>>> return 0;
>>>> }
>
> [Snippity doo dah.]
>
>> Take fir's example code above; a simple single call to
>> RecolorizePixelAndAdjacentOnes() will effectively recolour the
>> origin cell multiple times, because of how the recursion is handled.
>
> No, I don't think so. You seem to have missed the fact that it checks
> the colour of the "current" pixel, and only continues (setting new
> colour & recursing) if it is the old colour.
> Of course, I'm infering (guessing) the functionality, at least
> partially (Unsafe? Safe?), of GetPixelUnsafe() and SetPixelSafe() based
> on their names.
>
> [Snip Lew's examples.]
>
Safe and Unsafe means that Safe checks if the x,y is in the array of
pixels, when Unsafe just writes without checking - i draw in array of
unsigned 32 bit ARGB or GBRA (never remeber) pixels - then i blit that
'bitmap' on window client size as it can be done in winapi
here are exact code
inline void SetPixelUnsafe(int x, int y, unsigned color)
{
extern int frame_size_x ;
extern int frame_size_y ;
extern unsigned int* frame_bitmap ;
frame_bitmap[y*frame_size_x+x]=color;
}
inline void SetPixelSafe(int x, int y, unsigned color)
{
// if(frame==0) ERROR_EXIT("frame is zero in setpixelsafe ");
if(x<0) return;
if(x>frame_size_x-1) return;
if(y<0) return;
if(y>frame_size_y-1) return;
frame_bitmap[y*frame_size_x+x]=color;
}
there was soem mistake in that function before as if i check already i
should be using Unsafe versions of setpixel and getpixel but i tested
this for work not for optimisation so i didnt care
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-03-16 19:13 +0000 |
| Message-ID | <ut4r0q$31rir$1@dont-email.me> |
| In reply to | #383647 |
On 16/03/2024 04:11, fir wrote:
> i was writing simple editor (something like paint but more custom for my
> eventual needs) for big pixel (low resolution) drawing
>
> it showed in a minute i need a click for changing given drawed area of
> of one color into another color (becouse if no someone would need to do
> it by hand pixel by pixel and the need to change color of given element
> is very common)
>
> there is very simple method of doing it - i men i click in given color
> pixel then replace it by my color and call the same function on adjacent
> 4 pixels (only need check if it is in screen at all and if the color to
> change is that initial color
>
> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
> unsigned new_color)
> {
> if(old_color == new_color) return 0;
>
> if(XYIsInScreen( x, y))
> if(GetPixelUnsafe(x,y)==old_color)
> {
> SetPixelSafe(x,y,new_color);
> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
> return 1;
> }
>
> return 0;
> }
>
> it work but im not quite sure how to estimate the safety of this -
On my machine, it's OK up to a 400x400 image (starting with all one
colour and filling from the centre with another colour).
At 500x500, I get stack overflow. The 400x400 the maximum recursion
depth is 80,000 calls.
I don't an alternative ATM, I'm just reporting what I saw with my test
program shown below, since some here don't believe that recursion can be
problematical.
--------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef unsigned char byte;
enum {dimx=400};
enum {dimy=dimx};
byte image[dimx][dimy];
int maxdepth;
byte getpixel(int x, int y) {
return image[x][y];
}
void setpixel(int x, int y, byte newcol) {
image[x][y]=newcol;
}
int onscreen(int x, int y) {
return x>=0 && x<dimx && y>=0 && y<dimy;
}
void fill(int x, int y, unsigned old_color, unsigned new_color)
{
if(old_color == new_color) return;
static int depth=0;
++depth;
if (depth>maxdepth) maxdepth=depth;
if(onscreen( x, y)) {
//printf("FILL %d %d %d depth:%d\n",x,y, onscreen(x,y), depth);
if(getpixel(x,y)==old_color)
{
setpixel(x,y,new_color);
fill(x+1, y, old_color, new_color);
fill(x-1, y, old_color, new_color);
fill(x, y-1, old_color, new_color);
fill(x, y+1, old_color, new_color);
--depth;
return;
}
}
--depth;
return;
}
static void writepgm(byte* file) {
int x, y;
void* f;
f = fopen(file,"w");
fprintf(f,"%s\n","P2");
fprintf(f,"%d %d\n",dimx,dimy);
fprintf(f,"255\n");
for (y=0; y<dimy; ++y) {
for (x=0; x<dimx; ++x) {
fprintf(f,"%u%s",image[y][x]," ");
}
fprintf(f,"\n");
}
fclose(f);
}
int main(void) {
fill(dimx/2, dimy/2, 0, 80);
printf("maxdepth=%d\n",maxdepth);
puts("");
puts("Writing test.ppm:");
writepgm("test.ppm");
}
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-03-16 20:23 +0000 |
| Message-ID | <ut4v4r$32mgb$1@dont-email.me> |
| In reply to | #383661 |
On 16/03/2024 19:13, bart wrote:
> On 16/03/2024 04:11, fir wrote:
>> i was writing simple editor (something like paint but more custom for
>> my eventual needs) for big pixel (low resolution) drawing
>>
>> it showed in a minute i need a click for changing given drawed area of
>> of one color into another color (becouse if no someone would need to
>> do it by hand pixel by pixel and the need to change color of given
>> element is very common)
>>
>> there is very simple method of doing it - i men i click in given color
>> pixel then replace it by my color and call the same function on
>> adjacent 4 pixels (only need check if it is in screen at all and if
>> the color to change is that initial color
>>
>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
>> unsigned new_color)
>> {
>> if(old_color == new_color) return 0;
>>
>> if(XYIsInScreen( x, y))
>> if(GetPixelUnsafe(x,y)==old_color)
>> {
>> SetPixelSafe(x,y,new_color);
>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>> return 1;
>> }
>>
>> return 0;
>> }
>>
>> it work but im not quite sure how to estimate the safety of this -
>
> On my machine, it's OK up to a 400x400 image (starting with all one
> colour and filling from the centre with another colour).
>
> At 500x500, I get stack overflow. The 400x400 the maximum recursion
> depth is 80,000 calls.
For an NxN image filling from the centre, the max depth is N*N/2, or
from one corner, it's N*N.
The depth with an N*1 image starting from one end seems to just N.
It appears to fill as much as possible (in my tests, all remaining
pixels), before returning from any call, at which point, the work is done.
I've just looked in my Computer Graphics Principles and Practice book
(after blowing off the dust), and the algorithm above is exactly the
'FloodFill4' one in the book. It mentions the problems with the stack;
maybe I should have looked in there first.
It talks about better approaches, but it doesn't give a better algorithm
that I can see. Perhaps the OP should just do an online search for one.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-03-16 20:29 +0000 |
| Message-ID | <ut4vgb$32kbs$1@dont-email.me> |
| In reply to | #383664 |
On 16/03/2024 20:23, bart wrote:
> On 16/03/2024 19:13, bart wrote:
>> On 16/03/2024 04:11, fir wrote:
>>> i was writing simple editor (something like paint but more custom for
>>> my eventual needs) for big pixel (low resolution) drawing
>>>
>>> it showed in a minute i need a click for changing given drawed area of
>>> of one color into another color (becouse if no someone would need to
>>> do it by hand pixel by pixel and the need to change color of given
>>> element is very common)
>>>
>>> there is very simple method of doing it - i men i click in given
>>> color pixel then replace it by my color and call the same function on
>>> adjacent 4 pixels (only need check if it is in screen at all and if
>>> the color to change is that initial color
>>>
>>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
>>> unsigned new_color)
>>> {
>>> if(old_color == new_color) return 0;
>>>
>>> if(XYIsInScreen( x, y))
>>> if(GetPixelUnsafe(x,y)==old_color)
>>> {
>>> SetPixelSafe(x,y,new_color);
>>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>>> return 1;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> it work but im not quite sure how to estimate the safety of this -
>>
>> On my machine, it's OK up to a 400x400 image (starting with all one
>> colour and filling from the centre with another colour).
>>
>> At 500x500, I get stack overflow. The 400x400 the maximum recursion
>> depth is 80,000 calls.
>
> For an NxN image filling from the centre, the max depth is N*N/2, or
> from one corner, it's N*N.
>
> The depth with an N*1 image starting from one end seems to just N.
>
> It appears to fill as much as possible (in my tests, all remaining
> pixels), before returning from any call, at which point, the work is done.
>
> I've just looked in my Computer Graphics Principles and Practice book
> (after blowing off the dust), and the algorithm above is exactly the
> 'FloodFill4' one in the book. It mentions the problems with the stack;
> maybe I should have looked in there first.
>
> It talks about better approaches, but it doesn't give a better algorithm
> that I can see. Perhaps the OP should just do an online search for one.
>
>
>
Now think about adding some barriers. But don't make life too easy for
Scott.
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-03-20 01:48 +0100 |
| Message-ID | <utdbp4$2edhm$1@i2pn2.org> |
| In reply to | #383661 |
bart wrote:
> On 16/03/2024 04:11, fir wrote:
>> i was writing simple editor (something like paint but more custom for
>> my eventual needs) for big pixel (low resolution) drawing
>>
>> it showed in a minute i need a click for changing given drawed area of
>> of one color into another color (becouse if no someone would need to
>> do it by hand pixel by pixel and the need to change color of given
>> element is very common)
>>
>> there is very simple method of doing it - i men i click in given color
>> pixel then replace it by my color and call the same function on
>> adjacent 4 pixels (only need check if it is in screen at all and if
>> the color to change is that initial color
>>
>> int RecolorizePixelAndAdjacentOnes(int x, int y, unsigned old_color,
>> unsigned new_color)
>> {
>> if(old_color == new_color) return 0;
>>
>> if(XYIsInScreen( x, y))
>> if(GetPixelUnsafe(x,y)==old_color)
>> {
>> SetPixelSafe(x,y,new_color);
>> RecolorizePixelAndAdjacentOnes(x+1, y, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x-1, y, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x, y-1, old_color, new_color);
>> RecolorizePixelAndAdjacentOnes(x, y+1, old_color, new_color);
>> return 1;
>> }
>>
>> return 0;
>> }
>>
>> it work but im not quite sure how to estimate the safety of this -
>
> On my machine, it's OK up to a 400x400 image (starting with all one
> colour and filling from the centre with another colour).
>
> At 500x500, I get stack overflow. The 400x400 the maximum recursion
> depth is 80,000 calls.
>
i was slightly thinking a bit of this recursion more generally and
i observed that those very long depth chains are kinda problem of this
recursion becouse maybe it is more fitted to be run parrallel
if yu would just 'fork' that one call on 4 parallel calls you dont get
that problem - as it then works like 'horisontal' (shallow, like in
shallow searh) not 'vertical' (in-depth, deep search)
and if someone would rewrite in on non recursion way then it would be
natural to rewrite it to work horisontal -w hich is better
if someone would fork it in really parallel then the program of
sybchronistation of ram accesses appears
this observation hovewer may be seen as a strength of resursion -
as it naturally shows it works good with micro-paralelisation
(crowd of execution channels)
[toc] | [prev] | [next] | [standalone]
| From | Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> |
|---|---|
| Date | 2024-03-22 13:04 +1100 |
| Message-ID | <ni5vck-5r1.ln1@hendrix.foo> |
| In reply to | #383760 |
Groovy hepcat fir was jivin' in comp.lang.c on Wed, 20 Mar 2024 11:48
am. It's a cool scene! Dig it.
> i was slightly thinking a bit of this recursion more generally and
> i observed that those very long depth chains are kinda problem of this
> recursion becouse maybe it is more fitted to be run parrallel
I wasn't going to post this here, since it's really an algorithm
issue, rather than a C issue. But the thread seems to have gone on for
some time with you seeming to be unable to solve this. So I'll give you
this as a clue.
The (or, at least, a) solution is only partially recursive. What I
have used is a line-based algorithm, each line being filled iteratively
(in a simple loop) from left to right. Recursion from line to line
completes the algorithm. Thus, the recursion level is greatly reduced.
And you should find that this approach fills an area of any shape.
Note, however, that for some pathological cases (very large and
complex shapes), this can still create a fairly large level of
recursion. Maybe a more complex approach can deal with this. What I
present here is just a very simple one which, in most cases, should
have a level of recursion well within reason.
I use a two part approach. The first part (called floodfill in the
code below) just sets up for the second part. The second part (called
r_floodfill here, for recursive floodfill) does the actual work, but is
only called by floodfill(). It goes something like this (although this
is incomplete, untested and not code I've actually used, just an
example):
static void r_floodfill(unsigned y, unsigned x, pixel_t new_clr, pixel_t
old_clr)
{
unsigned start, end;
/* Find start and end of line within floodfill area. */
start = end = x;
while(old_clr == get_pixel(y, start - 1))
--start;
while(old_clr == get_pixel(y, end + 1))
++end;
/* Fill line with new colour. */
for(x = start; x <= end; x++)
set_pixel(y, x, new_clr);
/* Run along again, checking pixel colours above and below,
and recursing if appropriate. */
for(x = start; x <= end; x++)
{
if(old_clr == get_pixel(y - 1, x))
r_floodfill(y - 1, x, new_clr, old_clr);
if(old_clr == get_pixel(y + 1, x))
r_floodfill(y + 1, x, new_clr, old_clr);
}
}
void floodfill(unsigned y, unsigned x, pixel_t new_clr)
{
pixel_t old_clr = get_pixel(y, x);
/* Only proceed if colours differ. */
if(new_clr != old_clr)
r_floodfill(y, x, new_clr, old_clr);
}
To use this, simply call floodfill() passing the coordinates of the
starting point for the fill (y and x) and the fill colour (new_clr).
--
----- Dig the NEW and IMPROVED news sig!! -----
-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-22 17:55 +0300 |
| Message-ID | <20240322175526.00007505@yahoo.com> |
| In reply to | #383870 |
On Fri, 22 Mar 2024 13:04:39 +1100
Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> wrote:
> Groovy hepcat fir was jivin' in comp.lang.c on Wed, 20 Mar 2024 11:48
> am. It's a cool scene! Dig it.
>
> > i was slightly thinking a bit of this recursion more generally and
> > i observed that those very long depth chains are kinda problem of
> > this recursion becouse maybe it is more fitted to be run parrallel
>
> I wasn't going to post this here, since it's really an algorithm
> issue, rather than a C issue. But the thread seems to have gone on for
> some time with you seeming to be unable to solve this. So I'll give
> you this as a clue.
> The (or, at least, a) solution is only partially recursive. What I
> have used is a line-based algorithm, each line being filled
> iteratively (in a simple loop) from left to right. Recursion from
> line to line completes the algorithm. Thus, the recursion level is
> greatly reduced. And you should find that this approach fills an area
> of any shape. Note, however, that for some pathological cases (very
> large and complex shapes), this can still create a fairly large level
> of recursion. Maybe a more complex approach can deal with this. What I
> present here is just a very simple one which, in most cases, should
> have a level of recursion well within reason.
> I use a two part approach. The first part (called floodfill in the
> code below) just sets up for the second part. The second part (called
> r_floodfill here, for recursive floodfill) does the actual work, but
> is only called by floodfill(). It goes something like this (although
> this is incomplete, untested and not code I've actually used, just an
> example):
>
> static void r_floodfill(unsigned y, unsigned x, pixel_t new_clr,
> pixel_t old_clr)
> {
> unsigned start, end;
>
> /* Find start and end of line within floodfill area. */
> start = end = x;
> while(old_clr == get_pixel(y, start - 1))
> --start;
> while(old_clr == get_pixel(y, end + 1))
> ++end;
>
> /* Fill line with new colour. */
> for(x = start; x <= end; x++)
> set_pixel(y, x, new_clr);
>
> /* Run along again, checking pixel colours above and below,
> and recursing if appropriate. */
> for(x = start; x <= end; x++)
> {
> if(old_clr == get_pixel(y - 1, x))
> r_floodfill(y - 1, x, new_clr, old_clr);
> if(old_clr == get_pixel(y + 1, x))
> r_floodfill(y + 1, x, new_clr, old_clr);
> }
> }
>
> void floodfill(unsigned y, unsigned x, pixel_t new_clr)
> {
> pixel_t old_clr = get_pixel(y, x);
>
> /* Only proceed if colours differ. */
> if(new_clr != old_clr)
> r_floodfill(y, x, new_clr, old_clr);
> }
>
> To use this, simply call floodfill() passing the coordinates of the
> starting point for the fill (y and x) and the fill colour (new_clr).
>
It looks like anisotropic variant of my St. George Cross algorithm.
Or like recursive variant of Malcolm's algorithm.
Being anisotropic, it has higher amount of glass jaws. In particular,
it would be very slow for not uncommon 'jail window' patterns.
* *** *** *** ***
* * * * * * * * *
* * * * * * * * *
* * * * * * * * *
* * * * * * * * *
* * * * * * * * *
* * * * * * * * *
* * * * * * * * *
* * * * * * * * *
*** *** *** *** *
Also, implementation is still recursive and the worst-case recursion
depth is still O(N), where N is total number of recolored pixels, so
unlike many other solutions presented here, you didn't solve fir's
original problem.
And in presented form it's not thread-safe. Which is not a problem for
fir, but nonn-desirable for the rest of us.
Conclusion: sorry, you aren't going to get a cookie for your effort.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-03-22 18:31 +0300 |
| Message-ID | <20240322183116.00003ede@yahoo.com> |
| In reply to | #383874 |
On Fri, 22 Mar 2024 17:55:26 +0300
Michael S <already5chosen@yahoo.com> wrote:
> On Fri, 22 Mar 2024 13:04:39 +1100
> Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> wrote:
>
> >
> > To use this, simply call floodfill() passing the coordinates of
> > the starting point for the fill (y and x) and the fill colour
> > (new_clr).
>
> It looks like anisotropic variant of my St. George Cross algorithm.
> Or like recursive variant of Malcolm's algorithm.
> Being anisotropic, it has higher amount of glass jaws. In particular,
> it would be very slow for not uncommon 'jail window' patterns.
> * *** *** *** ***
> * * * * * * * * *
> * * * * * * * * *
> * * * * * * * * *
> * * * * * * * * *
> * * * * * * * * *
> * * * * * * * * *
> * * * * * * * * *
> * * * * * * * * *
> *** *** *** *** *
>
> Also, implementation is still recursive and the worst-case recursion
> depth is still O(N), where N is total number of recolored pixels, so
> unlike many other solutions presented here, you didn't solve fir's
> original problem.
> And in presented form it's not thread-safe. Which is not a problem for
> fir, but nonn-desirable for the rest of us.
>
> Conclusion: sorry, you aren't going to get a cookie for your effort.
>
So, what is my own practical answer?
Assuming that speed is not a top priority and that simplicity
is pretty high on priority scale and that it should work with big
images and default stack size under Windows, I will go with following
not particularly fast and not particularly slow algorithm that I call
"deferred stack". That is, it's mostly explicit stack, but (explicit)
recursion is deferred until all four neighbors of current pixel saved
on todo stack.
"Not particularly slow" means that I did see cases where some other
algorithms is 2 times faster, but had never seen 3x difference.
In case x and y are known to fit in uint16_t, UI type could be redefined
accordingly. It will make execution faster, but not by much.
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
typedef unsigned char Color;
typedef int UI;
int floodfill_r(
Color *image,
int width,
int height,
int x0,
int y0,
Color old,
Color new)
{
if (width < 0 || height < 0)
return 0;
if (x0 < 0 || x0 >= width || y0 < 0 || y0 >= height)
return 0;
size_t x = x0;
size_t y = y0;
if (image[y*width+x] != old)
return 0;
const ptrdiff_t INITIAL_TODO_SIZE = 128;
struct Point { UI x, y; } ;
struct Point *todo = malloc(INITIAL_TODO_SIZE * sizeof *todo );
if (!todo)
return -1;
struct Point* todo_end = &todo[INITIAL_TODO_SIZE];
todo[0].x = x; todo[0].y = y;
struct Point* sp = &todo[1];
do {
x = sp[-1].x; y = sp[-1].y;
--sp;
if (image[y*width+x] == old) {
image[y*width+x] = new;
if (x > 0 && image[y*width+x-1] == old) {
sp->x = x - 1; sp->y = y; ++sp;
}
if (y > 0 && image[y*width+x-width] == old) {
sp->x = x; sp->y = y - 1; ++sp;
}
if (x+1 < width && image[y*width+x+1] == old) {
sp->x = x + 1; sp->y = y; ++sp;
}
if (y+1 < height && image[y*width+x+width] == old) {
sp->x = x; sp->y = y + 1; ++sp;
}
if (todo_end-sp < 4) {
ptrdiff_t used = sp-todo;
ptrdiff_t size = todo_end - todo;
size += size/4;
struct Point* new_todo = realloc(todo, size * sizeof *todo );
if(!new_todo) {
free(todo);
return -1;
}
todo = new_todo;
sp = &todo[used];
todo_end = &todo[size];
}
}
} while (sp != todo);
free( todo );
return 1;
}
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-03-23 11:06 +0100 |
| Message-ID | <utm9jn$2pfmj$1@i2pn2.org> |
| In reply to | #383870 |
Peter 'Shaggy' Haywood wrote:
> Groovy hepcat fir was jivin' in comp.lang.c on Wed, 20 Mar 2024 11:48
> am. It's a cool scene! Dig it.
>
>> i was slightly thinking a bit of this recursion more generally and
>> i observed that those very long depth chains are kinda problem of this
>> recursion becouse maybe it is more fitted to be run parrallel
>
> I wasn't going to post this here, since it's really an algorithm
> issue, rather than a C issue. But the thread seems to have gone on for
> some time with you seeming to be unable to solve this. So I'll give you
> this as a clue.
> The (or, at least, a) solution is only partially recursive. What I
> have used is a line-based algorithm, each line being filled iteratively
> (in a simple loop) from left to right. Recursion from line to line
> completes the algorithm. Thus, the recursion level is greatly reduced.
> And you should find that this approach fills an area of any shape.
> Note, however, that for some pathological cases (very large and
> complex shapes), this can still create a fairly large level of
> recursion. Maybe a more complex approach can deal with this. What I
> present here is just a very simple one which, in most cases, should
> have a level of recursion well within reason.
> I use a two part approach. The first part (called floodfill in the
> code below) just sets up for the second part. The second part (called
> r_floodfill here, for recursive floodfill) does the actual work, but is
> only called by floodfill(). It goes something like this (although this
> is incomplete, untested and not code I've actually used, just an
> example):
>
> static void r_floodfill(unsigned y, unsigned x, pixel_t new_clr, pixel_t
> old_clr)
> {
> unsigned start, end;
>
> /* Find start and end of line within floodfill area. */
> start = end = x;
> while(old_clr == get_pixel(y, start - 1))
> --start;
> while(old_clr == get_pixel(y, end + 1))
> ++end;
>
> /* Fill line with new colour. */
> for(x = start; x <= end; x++)
> set_pixel(y, x, new_clr);
>
> /* Run along again, checking pixel colours above and below,
> and recursing if appropriate. */
> for(x = start; x <= end; x++)
> {
> if(old_clr == get_pixel(y - 1, x))
> r_floodfill(y - 1, x, new_clr, old_clr);
> if(old_clr == get_pixel(y + 1, x))
> r_floodfill(y + 1, x, new_clr, old_clr);
> }
> }
>
> void floodfill(unsigned y, unsigned x, pixel_t new_clr)
> {
> pixel_t old_clr = get_pixel(y, x);
>
> /* Only proceed if colours differ. */
> if(new_clr != old_clr)
> r_floodfill(y, x, new_clr, old_clr);
> }
>
> To use this, simply call floodfill() passing the coordinates of the
> starting point for the fill (y and x) and the fill colour (new_clr).
>
well this is ok improvement for consideration - i hovever resolved a
problem even in 3 ways as you could note reading more carefully
1) put a stack to 100 MB and forget
2) ui wrote strightforward iteretive version (in draft) (this with
AddPixel(.. )
3) i noticed that the best method would be to introduce so called call
queue in c (probably best solution imo)
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web