tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Xor of stamps too fine in high resolution screens

[Bill K. <nb...@so...>]

On Fri, Mar 17, 2023 at 07:30:46AM -0400, Albert Cahalan wrote:
> On 3/17/23, Bill Kendrick <nb...@so...> wrote:
> > On Fri, Mar 17, 2023 at 12:41:19AM +0100, Pere Pujal i Carabantes wrote:
> 
> >> Pixels are too tiny that make hard to see the Xor,
> >> of course it is there and with a little of attention
> >> one sees it but it is hard to see.
> >>
> >> I wonder if we could make the Xor thicker so it is
> >> easy to see.
> 
> Thicker in which way? The dots could be thicker,
> or the outline could be thicker, or both.
<snip>

Thanks for the description of how it works.  (Funny to learn
only that "8" was ever used... room for some simplification?)

I went with simply making the outline thicker, and I totally
cheated, but I think it looks fine and will hopefully be
helpful on devices with high dot pitch (like my phone).

When it decides it's worth XOR'ing a pixel, it now also does
this:

 * If it's _NOT_ already going to XOR the adjacent pixel to the right, XOR it too
 * Ditto for the adjacent pixel below
 * Ditto for the adjacent pixel below & to the right

So basically -- ASCII art coming -- if before we were doing this:

  #-#-#-
  -....#
  #....-
  -....#
  #-#-#-

(where "#" is an XOR'd pixel, and "-" would be a XOR'd pixel,
except for the stiple pattern telling us to skip it)

We will now do this:

 #-#-#-#
 -#-#-#-
 #-...-#
 -#...#-
 #-#-#-#
 -#-#-#-

It tries to turn what was a point before into a square
(but still stipled).


It looks fine to me on my laptop and my external monitors.
Both are 1920x1080.  The external is a 23", so about 96ppi.
The laptop is 14", so almost 160ppi.

Wikipedia tells me my phone (a plain (non pro) Pixel 7)
has a PPI of 416.  Wow, no wonder I can't see anything on it!

Pere & others, how does it look to you with this change?

-bill!

Re: [Tuxpaint-devel] Xor of stamps too fine in high resolution screens

[Albert C. <aca...@gm...>]

On 3/17/23, Bill Kendrick <nb...@so...> wrote:
> On Fri, Mar 17, 2023 at 12:41:19AM +0100, Pere Pujal i Carabantes wrote:

>> Pixels are too tiny that make hard to see the Xor,
>> of course it is there and with a little of attention
>> one sees it but it is hard to see.
>>
>> I wonder if we could make the Xor thicker so it is
>> easy to see.

Thicker in which way? The dots could be thicker,
or the outline could be thicker, or both.

> There's a stiple[] array used when doing the stamp XOR,
> but I honestly don't understand it.  I need to look at it.

It defines the dot pattern. Oddly, only the "8" matters.
I don't remember why. This is the one in use:

#define STIPLE_W 5
#define STIPLE_H 5
static char stiple[] = "84210" "10842" "42108" "08421" "21084";

To make dots thicker, that must be scaled. To make the outlines
thicker, something else needs to be scaled. (something about
calculating the stamp outline probably) If both should be scaled,
which seems likely, then perhaps that should be done together
when acting on the screen, leaving the non-screen data small.

To try out scaling only the dots:

#define STIPLE_W 10
#define STIPLE_H 10
static char stiple[] =
"8844221100"
"8844221100"
"1100884422"
"1100884422"
"4422110088"
"4422110088"
"0088442211"
"0088442211"
"2211008844"
"2211008844"
;

I just doubled everything, making dots 2x2 instead of 1x1.

Of course this is no good for compiling a single binary to support
multiple screen sizes, and again it doesn't do anything about the
thickness of the stamp outline that is being XORed onto the screen.

These things should scale directly with screen size, not like
the stamps do. (stamps scale with the square root of the screen
size in order to balance the competing desires of using larger
screens for more detail and for more room to draw)

There is something to be said for keeping Tux Paint small in the
pixels it internally handles, then asking the GPU to upscale the
whole thing. If there isn't a GPU, high resolution is unlikely.
The bad combo is probably only seen with virtual machines.

Re: [Tuxpaint-devel] Xor of stamps too fine in high resolution screens

[Bill K. <nb...@so...>]

On Fri, Mar 17, 2023 at 12:41:19AM +0100, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> Pixels are too tiny that make hard to see the Xor,
> of course it is there and with a little of attention 
> one sees it but it is hard to see.
> 
> I wonder if we could make the Xor thicker so it is 
> easy to see.

Ah, drat.


> Line and Shapes Xors are better seen.

Hrm, interesting!


> I don't think it is a stoper for release, but wanted 
> to mention here before I forget about it, 
> recently I got a replacement for my old phone 
> and saw this problem.

There's a stiple[] array used when doing the stamp XOR,
but I honestly don't understand it.  I need to look at it.
I'll open a ticket tomorrow.  I won't call it a "showstopper"
for 0.9.29, unless anyone thinks I should.

-bill!

[Tuxpaint-devel] Xor of stamps too fine in high resolution screens

[Pere P. i C. <per...@gm...>]

Hi all,

Pixels are too tiny that make hard to see the Xor,
of course it is there and with a little of attention 
one sees it but it is hard to see.

I wonder if we could make the Xor thicker so it is 
easy to see.

Line and Shapes Xors are better seen.


I don't think it is a stoper for release, but wanted 
to mention here before I forget about it, 
recently I got a replacement for my old phone 
and saw this problem.

Best
Pere

[Tuxpaint-devel] More recent developments: Saturation & kaleidoscope magic tools, color 'grabbing', shapes improvements

[Bill K. <nb...@so...>]

B0;115;0c
Briefly, here are a few other things I've committed recently,
in case anyone out here wants to try them out, provide feedback,
or propose code changes...  (Apologies if I've already mentioned
any of these here!)

 * "Saturate" & "Desaturate" magic tools

   Similar to how "Darken" and "Lighten" let you adjust the value of
   pixels, this lets you adjust the saturation levels.

   Example: https://tuxpaint.org/latest/sshots/tuxpaint-0.9.29-sat-desat.png


 * "Remove Color" & "Keep Color" magic tools

   Variations on the "Desaturate" tool, these use the
   currently-selected color (i.e., what you'd paint with), and apply
   100% desaturation to pixels on the canvas that are the same hue
   ("Remove") or NOT the same hue ("Keep") as that color.

   Example: https://tuxpaint.org/latest/sshots/tuxpaint-0.9.29-kaleidoscope-keep-remove-colors.png


 * "Kaleido-#" magic tools

   Various versions of a kaleidoscopic lens effect; attempts to
   simulate looking at your canvas through kaleidoscopes with
   various mirror angles (and hence levels of repetition):
   90-degrees (4-way), 60-degress (6-way), and 456-degrees (8-way).
   (It's interactive; move the mouse around to adjust which parts of
   the drawing appear in the slices. It's fun!)

   Example: https://twitter.com/TuxPaintTweets/status/1633033494799736833/photo/1


 * Cross-color-tool "grabbing" of colors

   When using the rainbow (HSV) color-picker, I kept wishing I could
   start with a color I picked up from the canvas using the pipette tool,
   or a color I created myself with the mixer.  Now you can!

   It will show 2 or 3 buttons that will set the crosshairs on the
   rainbow color-picker so that they match either of those (or one of
   the built-in colors, if that's what was chosen at the time you
   opened up the rainbow color-picker dialog).  Then you can move the
   crosshairs to "fine tune" the color.

   Note: I considered adding a similar function to the color mixer
   (where you blend ratios of red, yellow, blue, black, grey, and white),
   but (1) it's not easy, (2) the only way I could think of doing it
   was brute-force, and (3) I _think_ we can probably live with out.
   (More features = more complexity, and potential for confusion!)

   Video: https://twitter.com/TuxPaintTweets/status/1631595240208613377
   Screenshot: https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/docs/html/images/colors_rainbow_palette.png


 * Shapes tool improvements

   I kept finding it annoying when I'd using the Shapes tool in the
   "from the corner" (vs. the old-style "from the center") mode,
   shapes would always appear in the same orientation regardless
   as to whether I clicked and dragged downwards, or upwards.

   So now, an upwards drag will cause shapes (where it makes any
   difference, like triangle or the 5-pointed star) to start out
   rotated 180-degrees versus how they always appeared before.
   (A downward drag starts them at 0-degrees, as before.)

   Also, the "from the corner" shapes always rotated ABOUT their
   initial click point (the corner of their bounding box), and
   not AROUND their own center!  That bugged me so much, so I
   finally tackled that.

   Video: https://twitter.com/TuxPaintTweets/status/1632671412245925889


I'm gearing up for a release soon (unless I have any other hair-brained
ideas!)  The major to-do items I have left right now is creating some
icons and sound effects for some of the new Magic tools.


All told, this new version (0.9.29) will have 15 new Magic tools!
(Maze, Googly Eyes, Circles & Rays, Fur, 3D Glasses & Color Separation,
Saturate & Desaturate, Keep & Remove color, Kaleido-4, -6, and -8, and
Bloom)

Plus:

 * It will introduce a rotation step with the Stamps tool.

 * The Fill tool gains a Shaped (bevel) gradient mode.

 * The rainbow color-picker can utilize colors chosen in other parts of
   the color palette.

 * Deleted images go into the Trash on macOS.

 * Templates & Starters can be (and many are) scaled in different ways
   when they don't match the canvas' aspect ratio.

 * A very brief Quickstart Guide has been added.

 * There'll be a keyboard shortcut to access the small Eraser.

 * An "auto" button size option is now available.


...plus many other small improvements, bug fixes, translation updates,
and what-not!  It's been a busy 7- or 8-months since the last release!


Please test all these new things, if you have time & interest.
Thanks in advance!

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Kaleidoscopic lens Magic tools

[Bill K. <nb...@so...>]

I've added a pair of new tools, "Kaleido-4" and "Kaleido-6",
which apply a kaleidoscopic lens effect to the image,
either 4-way (90-degree) or 6-day (60-degree).  It's interactive
(with a low-res preview), which is a lot of fun :)

  https://twitter.com/TuxPaintTweets/status/1630858851154264064

Feedback welcome, as usual!

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Saturation tools

[Bill K. <nb...@so...>]

Other than the "Tint" tool, when used with a saturation-less color
selection (like black or white), there was no way to desaturate parts
of a picture in Tux Paint.  And that was all-or-nothing -- you could
'tint' parts of your picture into greyscale, but not do anything more
subtle.

So I added a pair of new tools, "Desaturate" and "Saturate", to go
along with the "Darken" and "Lighten" which affect the <getting into
dangerous waters, terminology-wise!> value or luminosity of the pixels.

In the end, I simply convert the RGB values into HSV, and then adjust
the S amount.  Right now I'm doing S = S * 3/4 for reduction, and
S = S * 4/3 for increase.  I could probably do better.

Here's an example, using the rocky beach template, and applying
"Desaturate" (via brush) a number of times on the left, and "Saturate"
on the right:

  https://tuxpaint.org/latest/sshots/tuxpaint-0.9.29-sat-desat.png

At one point, I went on a wild goose chase looking into whether using
different color spaces might produce even better results (i.e., converting
the RGB to XYZ then to LUV or L*a*b*) but then I remembered this is a
program meant for young kids, and I don't need to worry _too_ much about
perfection.


Then I decided to add two other saturation-related tools that might be
useful (if people think they are too strange or confusing to use, I
could be convinced to shelve them).  I called them "Keep Color" and
"Remove Color".  They totally desaturate parts of the image (turn it
completely greyscale -- the S in HSV becomes 0.0) based on the currently
selected color.

So for example say you have a colorful drawing with some red balloons.
They idea was to make it easy to turn the entire picture _except the
balloons_ into greyscale.

In this picture, I used "Reflection" to get a mirror-image of the
tree-and-sky photo template (so it's easy to see what's happening),
and the used "Remove Color" to remove the colors from blue sky at
the bottom, and [most of] the green tree leaves at the top.

  https://tuxpaint.org/latest/sshots/tuxpaint-0.9.29-keep-remove-colors.png

Note - All these tools need their own icons and sound effects.


I really need to stop adding new features, so we can get a release
out soon.  Our followers on Twitter are clamouring for some of these
new effects. ;-D

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] New "Bloom" effect added

[Bill K. <nb...@so...>]

On Sun, Feb 26, 2023 at 03:28:03PM +0100, Karl Ove Hufthammer wrote:
> Bill Kendrick skreiv 07.02.2023 10:43:
> >I got a little obsessed over the "bloom" effect, and was struggling to
> >understand Fast Fourier Transforms to get it done.  Maybe some day.
> >In the end, I brute-forced it and came up with an okay-looking (if not
> >awesome, and not fast) effect.  It's in the Git repo, please try it out.
> 
> I’m sure the math is complex, but at least on my system, it just
> looks like a *very* subtle ‘lighten’ effect.

It's meant to add a fringe around light parts of the image, to
simulate how bright lights affect how things look to a camera or
even to human eyes.

Here's an example where I created a brown background, with a slightly
lighter brown radial gradient, then drew some basic color bars
(white, yellow, cyan, green, etc.).  The 'glow' seen comes entirely
from the bloom effect being applied.

  https://pbs.twimg.com/media/Fp9DImxacAA-Bj2?format=png&name=small

Frankly, I would have loved to implement it using Fast Fourier Transforms,
but _that_ level of math has eluded me so far.


> And at first, I didn’t think it worked *at all*, as the thing I was
> drawing disappeared as soon as I let go of the mouse button. But
> after a bit more testing, I see that it does lighten (non-dark)
> areas somewhat and adds a (too) subtle glow effect.

Okay, I've tried changing "BLOOM_WEIGHT_CONST" from 0.025 to 0.05,
basically doubling it, and it's more obvious, without being too
overwhelming, I think.

-bill!

Re: [Tuxpaint-devel] Googly Eyes magic tool

[Bill K. <nb...@so...>]

On Sun, Feb 26, 2023 at 02:40:46PM +0100, Karl Ove Hufthammer wrote:
> Bill Kendrick skreiv 30.12.2022 01:21:
> >I recently added a "Googly Eyes" Magic tool to Tux Paint
> >(it appears as two options; small and large variations,
> >not unlike "Bricks" tool).
> >
> >Please pull from master, try it out, and report any issues!
> 
> Two issues:
> 
> Word puzzle in the .po file: ‘Click to place a %s, then drag and
> release to make it look that direction.’, where %s is replaced by
> either ‘large googly eye‘ and ‘small googly eye’. This probably
> won’t work for all languages. Replace it with two separate
> sentences.

Okay, done!  Thanks, as always.


> You wrote ‘Googly Eyes’ here and in the documentation, but in the
> actual application, it’s ‘Google Eyes’.

!! Wow I'm blind !!


> And shouldn’t it really be
> ‘Goggle-eyed’ (with one o and a hyphen), cf.
> https://dictionary.cambridge.org/dictionary/english/goggle-eyed? But
> there’s also https://en.wikipedia.org/wiki/Googly_eyes. In any case,
> ‘Google Eyes’ is probably wrong.

Goggle-eyed describes a look on someone's face, whereas googly-eyes are
a craft-making item that this Magic tool is meant to simulate. :)

Thanks!

-bill!

Re: [Tuxpaint-devel] New "Bloom" effect added

[Karl O. H. <ka...@hu...>]

Bill Kendrick skreiv 07.02.2023 10:43:
> I got a little obsessed over the "bloom" effect, and was struggling to
> understand Fast Fourier Transforms to get it done.  Maybe some day.
> In the end, I brute-forced it and came up with an okay-looking (if not
> awesome, and not fast) effect.  It's in the Git repo, please try it out.

I’m sure the math is complex, but at least on my system, it just looks 
like a *very* subtle ‘lighten’ effect.

And at first, I didn’t think it worked *at all*, as the thing I was 
drawing disappeared as soon as I let go of the mouse button. But after a 
bit more testing, I see that it does lighten (non-dark) areas somewhat 
and adds a (too) subtle glow effect.


-- 
Karl Ove Hufthammer

Re: [Tuxpaint-devel] Googly Eyes magic tool

[Karl O. H. <ka...@hu...>]

Bill Kendrick skreiv 30.12.2022 01:21:
> I recently added a "Googly Eyes" Magic tool to Tux Paint
> (it appears as two options; small and large variations,
> not unlike "Bricks" tool).
>
> Please pull from master, try it out, and report any issues!

Two issues:

Word puzzle in the .po file: ‘Click to place a %s, then drag and release 
to make it look that direction.’, where %s is replaced by either ‘large 
googly eye‘ and ‘small googly eye’. This probably won’t work for all 
languages. Replace it with two separate sentences.

You wrote ‘Googly Eyes’ here and in the documentation, but in the actual 
application, it’s ‘Google Eyes’. And shouldn’t it really be 
‘Goggle-eyed’ (with one o and a hyphen), cf. 
https://dictionary.cambridge.org/dictionary/english/goggle-eyed? But 
there’s also https://en.wikipedia.org/wiki/Googly_eyes. In any case, 
‘Google Eyes’ is probably wrong.


-- 
Karl Ove Hufthammer

Re: [Tuxpaint-devel] New Magic tool: "Color Sep." (color separation) -- comments appreciated

[Bill K. <nb...@so...>]

On Wed, Feb 22, 2023 at 03:51:36PM -0800, Bill Kendrick wrote:
> 
> I've created a new magic tool that allows you to separate
> one channel of a picture's color from another, via translation.
<snip>

Alright, I decided to split it into two tools:

 * 3D Glasses (red/cyan, horizontal only), and
 * Color Sep. (any color, any direction)

Off to bed with me!

-bill!

[Tuxpaint-devel] New Magic tool: "Color Sep." (color separation) -- comments appreciated

[Bill K. <nb...@so...>]

I've created a new magic tool that allows you to separate
one channel of a picture's color from another, via translation.

For example, the red/cyan option, when separating horizontally,
is useful to make anaglyphic pictures you can view with 3D glasses.
Here's a simple example:

  https://twitter.com/TuxPaintTweets/status/1628278912446009344

And here's a video of it in action:

  https://twitter.com/TuxPaintTweets/status/1628295483470024704


Currently, I let you choose a color to determine how the colors
separate.  If the color you pick contains more red than the
other two colors (blue & green), or conversely more of the other
two colors (i.e., cyan), then it will be a Red/Cyan separation.

If the color is fairly monochrome (black, grey, white), it will
default to the Red/Cyan setting.

Alternatively, I could just make three distinct tools, and deactivate
the color selections, if that seems less confusing.  Thoughts?


A couple more things to consider, that I'd love feedback on...

The Blue/Yellow (blue vs. red + green) separation is fairly difficult
to notice, but I'm assuming that's because human eyes are the least
sensitive to blue.  (Maybe even more so for me, as a male?)
I'm leaning towards keeping it as an option, to provide as much
variety as possible, though.

It reads individual pixels from the snapshot (input) canvas twice,
from two different offset positions, and then applies the results
(mixing different combinations of one or the other input pixels'
red/green/blue values) to the output canvas.  It does this for
_every pixel_, even as you're dragging the mouse around.
I'm curious whether this performs okay for everyone.  I could make
a preview that's much lower resolution, and then upon release,
it would process every single pixel.

It uses Tux Paint magic API's "getpixel", so when the offset is
off the edge of the canvas (as it literally always be, at least in
one direction), it smears.  (See the video.)  That seems okay to me.

As you drag, rather than moving one channel the direction of the
mouse, it moves one channel half that direction, and the other
two half in the opposite direction.  (See the video.)

If you simply click & release (no drag), it will offset horizontally
a small amount.  The 3D frog picture (static image linked above)
was created with the following steps:

 1. pick frog, shrink size & place it
 2. red/cyan offset (click+release)
 3. enlarge frog & place it again
 4. repeat steps 2 & 3 a few more times

The most-recently placed frog appears "close" to when I use my
red (left lens) / blue (right lens) 3D glasses.  The ones I
placed longest ago appear "far away".  It really had me giggling
when I tested it out.  It worked perfectly! >:-D

(Bonus silly image:
https://twitter.com/billkendrick/status/1628298259327488001)

I was thinking there might be ways for me to separate other
color combinations, but I'm not sure the best way of doing this.
Perhaps using percentages?  (This is why I based the separation
mode on the currently-chosen color.)

Maybe if I figure that out, I could have two tools:

 * 3D Glasses
   + Red/cyan mode only
   + Therefore, color options disabled
   + Only translates horizontally (ignores vertical motion)

 * Color Separation
   + Any color combination
   + Therefore. color options enabled
   + Translations in both dimensions (horizontal & vertical)

I can never leave well enough alone, can I? ;)


-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] New "Bloom" effect added

[Pere P. i C. <per...@gm...>]

El dg. 19 de 02 de 2023 a les 18:20 -0800, en/na Bill Kendrick va escriure:
> On Sat, Feb 18, 2023 at 11:30:43PM +0100, Pere Pujal i Carabantes wrote:
> > El dv. 17 de 02 de 2023 a les 21:48 -0800, en/na Bill Kendrick va escriure:
> > > On Thu, Feb 09, 2023 at 12:21:49AM +0100, Pere Pujal i Carabantes wrote:
> > > > That was in a debug build, a more regular build speeds up a lot
> > > > Check it at
> > > > https://provant.freeddns.org/pere/public_html/developing/20230109/
> > > 
> > > Thanks!
> > > 
> > > BTW, in testing this I realize the new stamp rotation feature is
> > > pretty terrible on a touchscreen, so I'm going to try and think of
> > > a way to make it easier to use. :-/
> > 
> > I see you are currently working in it, let me know if/when you want a new build to test
> 
> Basically, I've made it an option (default: off, to avoid changing
> behavior too much from earlier Tux Paint), and only rotate when
> dragging outside of the shape.
> 
> I think for larger shapes, this may be difficult, since you can't reach
> outside of them, but I'll keep thinking about it.  Maybe click+drag will
> act differently than simply dragging...?

Maybe also reduce the "0 rotation space" to the size of buttons instead of the stamp size?
Or just reduce it to 0 if the drag has already started to rotate?
 
> 
> It's definitely difficult trying to design something that makes sense
> with _both_ a mouse _and_ touchscreen! :-)
> 
> Please make a new build when you have time, and I'll play with it, and
> maybe see what my family members think of it.

I haven't tested it, my phone has some problems,
https://provant.freeddns.org/pere/public_html/developing/20230220/
> 
> -bill!
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] New "Bloom" effect added

[Bill K. <nb...@so...>]

On Sat, Feb 18, 2023 at 11:30:43PM +0100, Pere Pujal i Carabantes wrote:
> El dv. 17 de 02 de 2023 a les 21:48 -0800, en/na Bill Kendrick va escriure:
> > On Thu, Feb 09, 2023 at 12:21:49AM +0100, Pere Pujal i Carabantes wrote:
> > > That was in a debug build, a more regular build speeds up a lot
> > > Check it at
> > > https://provant.freeddns.org/pere/public_html/developing/20230109/
> > 
> > Thanks!
> > 
> > BTW, in testing this I realize the new stamp rotation feature is
> > pretty terrible on a touchscreen, so I'm going to try and think of
> > a way to make it easier to use. :-/
> 
> I see you are currently working in it, let me know if/when you want a new build to test

Basically, I've made it an option (default: off, to avoid changing
behavior too much from earlier Tux Paint), and only rotate when
dragging outside of the shape.

I think for larger shapes, this may be difficult, since you can't reach
outside of them, but I'll keep thinking about it.  Maybe click+drag will
act differently than simply dragging...?

It's definitely difficult trying to design something that makes sense
with _both_ a mouse _and_ touchscreen! :-)

Please make a new build when you have time, and I'll play with it, and
maybe see what my family members think of it.

-bill!

Re: [Tuxpaint-devel] New "Bloom" effect added

[Pere P. i C. <per...@gm...>]

El dv. 17 de 02 de 2023 a les 21:48 -0800, en/na Bill Kendrick va escriure:
> On Thu, Feb 09, 2023 at 12:21:49AM +0100, Pere Pujal i Carabantes wrote:
> > That was in a debug build, a more regular build speeds up a lot
> > Check it at
> > https://provant.freeddns.org/pere/public_html/developing/20230109/
> 
> Thanks!
> 
> BTW, in testing this I realize the new stamp rotation feature is
> pretty terrible on a touchscreen, so I'm going to try and think of
> a way to make it easier to use. :-/

I see you are currently working in it, let me know if/when you want a new build to test

Pere

> 
> -bill!
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] New "Bloom" effect added

[Bill K. <nb...@so...>]

On Thu, Feb 09, 2023 at 12:21:49AM +0100, Pere Pujal i Carabantes wrote:
> That was in a debug build, a more regular build speeds up a lot
> Check it at
> https://provant.freeddns.org/pere/public_html/developing/20230109/

Thanks!

BTW, in testing this I realize the new stamp rotation feature is
pretty terrible on a touchscreen, so I'm going to try and think of
a way to make it easier to use. :-/

-bill!

Re: [Tuxpaint-devel] Options for scaling starters & templates

[Bill K. <nb...@so...>]

On Sat, Feb 11, 2023 at 02:57:20AM -0500, Albert Cahalan wrote:
> You might want a gravity direction.This would cause the filling (smear
> or solid) or cropping to avoid one or two of the sides.
> 
> 0. center
> 1. left
> 2. right
> 3. top
> 4. bottom
> 5. bottom-left
> 6. bottom-right
> 7. top-left
> 8. top-right

Excellent idea, I've implemented this (as a separate option), and
somehow it wasn't too difficult.  I'm working to document it now;
that might be the hard part. ;)

Thanks to both you and Pere for putting though into this.


> Another option is to tile. This probably ought to scale the way stamps
> do, proportional to the fourth root of the canvas area. (that being a
> compromise for how to make use of larger screen size) Maybe the tiled
> ones should appear as 2x2 in the selection UI. Simple tiling is enough
> I think; there is no need for weird symmetries.

I'm gonna hold off on this idea, but I'll let it percolate
in my brain.  Thanks :)

-bill!

Re: [Tuxpaint-devel] Options for scaling starters & templates

[Albert C. <aca...@gm...>]

You might want a gravity direction.This would cause the filling (smear
or solid) or cropping to avoid one or two of the sides.

0. center
1. left
2. right
3. top
4. bottom
5. bottom-left
6. bottom-right
7. top-left
8. top-right

Another option is to tile. This probably ought to scale the way stamps
do, proportional to the fourth root of the canvas area. (that being a
compromise for how to make use of larger screen size) Maybe the tiled
ones should appear as 2x2 in the selection UI. Simple tiling is enough
I think; there is no need for weird symmetries.

Re: [Tuxpaint-devel] Options for scaling starters & templates

[Pere P. i C. <per...@gm...>]

El dv. 10 de 02 de 2023 a les 02:40 -0800, en/na Bill Kendrick va escriure:
> When a starter image or template is not the exact same size
> as the canvas, it will of course be scaled up or down.
> We do not change the aspect ratio (change the shape, aka
> squash or stretch) of the picture, though.
> 
> If the aspect ratio is not the same as the canvas (which it
> frequently is note), it will scale up as large as it can
> and then "smear" the edges that did not fill the canvas.
> This can look really weird & ugly, especially with the
> photographic ones (e.g., the rocky beach template).
> 
> I just started work to allow option files (plaintext config
> files with the same name as the image file, but with ".dat"
> extension; same as we do with stamps and brushes) to allow
> this to be overridden for some starters & templates.
> 
> I have done so already with the wool mill machinery, the
> rocky beach, and the reef (2-layer starter).  They've all
> been set to use the same option, "autoscale=both".
> 
> The "autoscale" option allows you to tell Tux Paint whether it's okay
> to scale the image up so much that the edges will be cropped away.
> For example, a wide starter on a narrow canvas can be scaled up so
> that it fits vertically, with the left/right sides getting discarded.
> 
> And conversely, a narrow starter on a wide canvas can be scaled up
> so that it fits horizontally, with the top/bottom discarded.
> 
> If it only makes sense to allow one dimension to be discarded
> (i.e., right & left is okay, but cutting off the top & bottom
> would be bad), you can specify either "autoscale=horizontal"
> or "autoscale=vertical".

Maybe also "autoscale=bottom" since in some starters is better to retain the upper part.

> 
> If no scaling is specified, it will scale up as much as it
> can without cropping anything, like it has been doing already.
> 
> Now, though, you can also specify whether or not to "smear"
> (which will be the default), or to simply use a solid background color
> (which you specify with "background=..." in the file; it supports
> 6- and 3-digit hex (e.g., #FFFFFF & #000) and decimal, just like the
> color palette file does.  This would be good for B&W coloring-book
> style starters (e.g., the skull SVG) which can sometimes end up
> with a very faint edge getting smeared all the way down the canvas.
> 
> Note: If the "autoscale=both" option is set, the image will NEVER have
> any bare edges, no matter the shape of the canvas.  So the background
> setting (smear, or use a background color) is moot.
> 
> I posted a tweet on Twitter showing the rocky beach template,
> with before & after in both portrait & landscape canvases of
> rather extreme sizes (Tux Paint running at 1280x640 and 640x960).
> 
> https://twitter.com/billkendrick/status/1623989004436901890
> 
> For the rocky beach template, for example, I don't think what's
> at the extreme edges "matters".  And I'd prefer to have a drawing
> that looks like some nice rocks, regardless of my canvas'
> aspect ratio, rather than weird smeary edges. :)
> 
> I need to test this a bunch more, document it (EXTENDING), and
> add sensible defaults for any starters & templates that would
> benefit from the different settings.
> 
> I cannot guarantee that Tux Paint will behave very well with starters
> & templates [*] if you save a drawing, quit, change the canvas size
> (via setting a different window size), launch Tux Paint again, and
> open the image up again.  However, I don't think it's done a great
> job with this _already_, so I'm not super concerned.
> 
> What you'll see is that I only apply this "scale & crop?" and
> "background color or smear?" decision when loading the actual
> starter/template images, and don't do it to the saved drawing.
> 
> It also gets a little tricky because as of late, we jam some
> of the starter & template stuff (including the entire background
> and foregrounds?!) into the PNG files, if I recall correctly.


Yes, IIRC this is drawing surface, old dat file contents,   
starter bakground and foreground surfaces, label surface (if any)   
and contents of labels.


As I see it, starter back and fore surfaces MUST be tied to the saved drawing   
and suffer the same changes as the saved drawing if the canvas change.

Currently, on Open, it regenerates the starter surfaces from the stored data   
without taking account of the changes in the drawing, so if the drawing   
has scaled because canvas changes, then the starter and drawing   
will not match anymore.

Also, some magic tools woul benefit of starter sync with drawing, like  
move, zoom, perspective...

my 2 cents  
Pere


> 
> Basically, woe is me, I don't think I can make this "perfect"...
> but I think this improvement is probably beneficial.
> 
> Holler if you have other ideas or concerns!
> 
> -bill!
> 
> [*] Starters would be more adversely affected since there is a top
> layer that applies itself to the image after every modification
> (paint, stamp, etc.)  Warped & zoom-in/out effects could be seen.
> Templates are less of a concern, as they only come into play -- the
> same way as the starters' background layers -- when you use the
> Eraser tool.
> 
> PS - This is https://sourceforge.net/p/tuxpaint/feature-requests/190/
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

[Tuxpaint-devel] Options for scaling starters & templates

[Bill K. <nb...@so...>]

When a starter image or template is not the exact same size
as the canvas, it will of course be scaled up or down.
We do not change the aspect ratio (change the shape, aka
squash or stretch) of the picture, though.

If the aspect ratio is not the same as the canvas (which it
frequently is note), it will scale up as large as it can
and then "smear" the edges that did not fill the canvas.
This can look really weird & ugly, especially with the
photographic ones (e.g., the rocky beach template).

I just started work to allow option files (plaintext config
files with the same name as the image file, but with ".dat"
extension; same as we do with stamps and brushes) to allow
this to be overridden for some starters & templates.

I have done so already with the wool mill machinery, the
rocky beach, and the reef (2-layer starter).  They've all
been set to use the same option, "autoscale=both".

The "autoscale" option allows you to tell Tux Paint whether it's okay
to scale the image up so much that the edges will be cropped away.
For example, a wide starter on a narrow canvas can be scaled up so
that it fits vertically, with the left/right sides getting discarded.

And conversely, a narrow starter on a wide canvas can be scaled up
so that it fits horizontally, with the top/bottom discarded.

If it only makes sense to allow one dimension to be discarded
(i.e., right & left is okay, but cutting off the top & bottom
would be bad), you can specify either "autoscale=horizontal"
or "autoscale=vertical".

If no scaling is specified, it will scale up as much as it
can without cropping anything, like it has been doing already.

Now, though, you can also specify whether or not to "smear"
(which will be the default), or to simply use a solid background color
(which you specify with "background=..." in the file; it supports
6- and 3-digit hex (e.g., #FFFFFF & #000) and decimal, just like the
color palette file does.  This would be good for B&W coloring-book
style starters (e.g., the skull SVG) which can sometimes end up
with a very faint edge getting smeared all the way down the canvas.

Note: If the "autoscale=both" option is set, the image will NEVER have
any bare edges, no matter the shape of the canvas.  So the background
setting (smear, or use a background color) is moot.

I posted a tweet on Twitter showing the rocky beach template,
with before & after in both portrait & landscape canvases of
rather extreme sizes (Tux Paint running at 1280x640 and 640x960).

https://twitter.com/billkendrick/status/1623989004436901890

For the rocky beach template, for example, I don't think what's
at the extreme edges "matters".  And I'd prefer to have a drawing
that looks like some nice rocks, regardless of my canvas'
aspect ratio, rather than weird smeary edges. :)

I need to test this a bunch more, document it (EXTENDING), and
add sensible defaults for any starters & templates that would
benefit from the different settings.

I cannot guarantee that Tux Paint will behave very well with starters
& templates [*] if you save a drawing, quit, change the canvas size
(via setting a different window size), launch Tux Paint again, and
open the image up again.  However, I don't think it's done a great
job with this _already_, so I'm not super concerned.

What you'll see is that I only apply this "scale & crop?" and
"background color or smear?" decision when loading the actual
starter/template images, and don't do it to the saved drawing.

It also gets a little tricky because as of late, we jam some
of the starter & template stuff (including the entire background
and foregrounds?!) into the PNG files, if I recall correctly.

Basically, woe is me, I don't think I can make this "perfect"...
but I think this improvement is probably beneficial.

Holler if you have other ideas or concerns!

-bill!

[*] Starters would be more adversely affected since there is a top
layer that applies itself to the image after every modification
(paint, stamp, etc.)  Warped & zoom-in/out effects could be seen.
Templates are less of a concern, as they only come into play -- the
same way as the starters' background layers -- when you use the
Eraser tool.

PS - This is https://sourceforge.net/p/tuxpaint/feature-requests/190/

Re: [Tuxpaint-devel] New "Bloom" effect added

[Pere P. i C. <per...@gm...>]

That was in a debug build, a more regular build speeds up a lot
Check it at
https://provant.freeddns.org/pere/public_html/developing/20230109/

Best
Pere

El dc. 08 de 02 de 2023 a les 13:29 +0100, en/na Pere Pujal i Carabantes va escriure:
> Hi Bill, and all,
> 
> El 7 de febrer de 2023 10:43:18 CET, Bill Kendrick <nb...@so...> ha escrit:
> > 
> > I got a little obsessed over the "bloom" effect, and was struggling to
> > understand Fast Fourier Transforms to get it done.  Maybe some day.
> > In the end, I brute-forced it and came up with an okay-looking (if not
> > awesome, and not fast) effect.  It's in the Git repo, please try it out.
> > (Pere, let me know how it performs on Android... it's a lot of math!)
> 
> I like this effect :)
> 
> I've build Tux Paint for Android and found Bloom performs fine in my 2016 midrange phone.
> Compared with Rush, Bloom is faster, it takes about 8 seconds to perform in fullscreen,
> Rush takes about the double.
> 
> I've noticed a couple of minor things:
> Rush lacks progressbar
> Googly eyes have the same icon and button string in both sizes making
> hard to diferentiate between them.
> 
> 
> > 
> > Thanks in advance!
> 
> HTH
> Pere

Re: [Tuxpaint-devel] New "Bloom" effect added

[Pere P. i C. <per...@gm...>]

Hi Bill, and all,

El 7 de febrer de 2023 10:43:18 CET, Bill Kendrick <nb...@so...> ha escrit:
>
>I got a little obsessed over the "bloom" effect, and was struggling to
>understand Fast Fourier Transforms to get it done.  Maybe some day.
>In the end, I brute-forced it and came up with an okay-looking (if not
>awesome, and not fast) effect.  It's in the Git repo, please try it out.
>(Pere, let me know how it performs on Android... it's a lot of math!)

I like this effect :)

I've build Tux Paint for Android and found Bloom performs fine in my 2016 midrange phone.
Compared with Rush, Bloom is faster, it takes about 8 seconds to perform in fullscreen,
Rush takes about the double.

I've noticed a couple of minor things:
Rush lacks progressbar
Googly eyes have the same icon and button string in both sizes making
hard to diferentiate between them.


>
>Thanks in advance!

HTH
Pere

[Tuxpaint-devel] New "Bloom" effect added

[Bill K. <nb...@so...>]

I got a little obsessed over the "bloom" effect, and was struggling to
understand Fast Fourier Transforms to get it done.  Maybe some day.
In the end, I brute-forced it and came up with an okay-looking (if not
awesome, and not fast) effect.  It's in the Git repo, please try it out.
(Pere, let me know how it performs on Android... it's a lot of math!)

Thanks in advance!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] More new magic tools - Maze, Fur, Circles, Rays

[Pere P. i C. <per...@gm...>]

El dt. 31 de 01 de 2023 a les 09:50 -0800, en/na Bill Kendrick va escriure:
> Since adding the "Googly Eyes" magic tool to what will become
> Tux Paint 0.9.29, I've added four more!
> 
> The "Maze" magic tool lets you 'paint' randomly-generated mazes
> over your picture.  You can create a few separate discontiguous
> areas, and connect them later (within the same session of using
> the tool).  That last part was tricky, but rewarding.
> 
>   https://tuxpaint.org/latest/sshots/tuxpaint-0.9.29-maze.png

Maze at 1920x1080, magic fullscreen let some areas with a solid 
color without maze, don't know if this is by design, increasing the
limit to 100000 works fine in my box and I get no more solid color
areas.

      while (state != STATE_DONE && iter < 100000);

Not sure what could happen in low end devices, but here,
even slowing Tux Paint with valgrind takes less than 2 seconds
to do the magic fullscreen effect.

I could not test in bigger displays, now Tux Paint refuses to 
increase the window size over the display size even if asked 
to do so.

Other than that, the new magic tools look nice :)

HTH
Pere
 
> 
> 
> My teenage son showed me a Scratch programming project [1] which
> simulated circular brush strokes, by sampling parts of a background
> and then selecting random spots on the image and drawing a stroke that
> was at a 90-degree angle to the direction the point was, to the
> cursor.  I turned this into the "Circles" magic tool.  I made a
> variation that skips the 90-degree step, and called it "Rays".
> You can see the results here:
> 
>   https://tuxpaint.org/latest/sshots/tuxpaint-0.9.29-circles-rays.png
>   https://twitter.com/TuxPaintTweets/status/1619582449830486016
> 
> 
> I then decided to see how it looked if I had the effect 'follow'
> the mouse, rather than stay in one place, which you can see
> demonstrated here:
> 
>   https://twitter.com/TuxPaintTweets/status/1619621388847050756
> 
> However, in the end, instead of doing that, I took the "Rays" effect,
> shrunk it down, made it draw based on your chosen color (rather than
> sampling from the existing image), and called it "Fur".  Here it is,
> together with "Googly Eyes" and "Bricks" to make a picture of Cookie
> Monster from Sesame Street! ;)
> 
>   https://twitter.com/TuxPaintTweets/status/1619926974453157890/photo/1
> 
> Anyway, please try them out & give any feedback.  Thanks!
>