Re: [Tuxpaint-dev] [PATCH] new tinter
On Thu, 2004-11-25 at 15:46, Albert Cahalan wrote: On Thu, 2004-11-25 at 14:50, Karl Ove Hufthammer wrote: I got an error message while trying to apply it for tuxpaint.c. Could you try resending it, now as a an attachment (line-breaking in e-mail programs easily mangles patches) and diffed against latest CVS version? Don't cut-and-paste. Save the email, then run the whole thing through patch. If you still get an error, check to be sure that some lame helpful mail gateway hasn't decided to prevent damage by using printed-quotable MIME encoding. Never use such evil mail gateways. Remember: cd root-of-tuxpaint-source patch -s -E -p1 path-to-this-email Use the --dry-run option if you want to check first. The patch came back to me OK. It applies without complaint. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Wed, 2004-11-24 at 06:13, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in +#define VIDEO_BPP 15 // saves memory This causes severe dithering artifacts. It's particularly visible on the colour buckets, which look look *really* bad now. Odd. Is your display actually in 16 bpp mode? For me, the 16 bpp value was horrid, and the 15 bpp value is indistinguishable from 24 or 32. My display is 32 bpp. +//#define VIDEO_BPP 16 // causes purple discoloration And even white (!) aren't properly handled! This setting is severely defective. Try this: Fill the screen with dark grey. Put a bunch of small light grey spots packed closely together, so that you can blur them to make a medium grey color. Now do that... and you see a purple tint after a while. +//#define VIDEO_BPP 24 // compromise +//#define VIDEO_BPP 32 // might be the fastest, if conversion functions removed Is there any reason we can't use 32 bit mode? Pro: 1. accurate 2. less bit shifting and alignment trouble 3. can rip out some slow N-bpp to 32-bpp conversion code Con: 1. undo buffers take up 2x space 2. less of the image will fit in the CPU's cache The record/playback feature could be used to benchmark this. After drawing enough to use up all the undo buffers, memory usage could be examined with ps, top, and pmap. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Wed, 2004-11-24 at 06:29, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: The Sky blue is actually that now, computed as the average value of the sky in numerous images of the sky. (if you try this, remember to allow for gamma) Likewise, tan and beige were computed from many images. The sky blue looks a bit too grey. I'll play around with a bit. I'd rather you didn't just manually tweak it. If you'd like a less overcast sky, I could compute what that would be. Unless you're in Arizona, look outside some time. The sky really is that grey. Maybe I should post a program for computing this; it'd expect to read in a correct (sRGB gamma, NOT 1.0 gamma) *.ppm file filled with patches of sky. (you cut-and-paste from a wide variety of sky pictures to get this) I really like the tan and beige colours, by the way. I'm really tired of apps using only fully-saturated colours. (Especially cyan hurts my eyes.) A more subdued palette is easier on the eye, and images drawn with these colours really look better. (And no, bright, satuared colours are not more 'fun' for kids!) In the sRGB color space, blue is dark and saturated. Yellow and cyan are not saturated. Yellow is bright. If we had more slots (could be an option -- they get smaller) I'd choose a dozen hues, with the brightness of both blue and yellow, at the maximum saturation (not much!) that can be shared by all the hue+brightness choices. I don't care for silver, since it doesn't sparkle or gleam, but I figured light grey might be to difficult to read. Huh? These are not colors: silver, gold, sparkely, chrome They refer primarily to some non-color light reflection properties. Well, the Tux Paint silver is a plain color. It doesn't do anything exotic and impossible, and doesn't even attempt to mimic the look via white highlights. But anyway, the buttons for all the greyscale colours look almost the same, so we should think about removing some of them. I'll try to come up with a proposal for a new colour palette. No, we should think about changing the way the buttons look. Either that, or live with it. The current buttons are pretty, but they don't handle all of the colors well. We need all 4 shades of grey -- I didn't change them, BTW. Clarity can be had at the expense of some beauty. Well, maybe you would find this beautiful! Beauty is in the eye of the beholder. Suggestion for clarity: Put some horizontal black stripes as the background of the color selector. (2 to 5 pixels thick) Add some elliptical patches of color, perhaps turned 15 degrees to the right. The color is the button, unmolested by shading effects that don't work quite right on black and white anyway. (This is easier said than done. One important thing to be aware of, is that all colours must give different tints when tinting stamps. We had a problem with magenta and purple before. The two colours looked completely different, but gave the same colour when tinting stamps. Some very minor modifications to the colour values fixed this.) I don't think that's a big problem. I'd rather have the original magenta and purple. (didn't change it back though) If the tinting code doesn't handle brightness, then that's the problem that needs fixing. Choosing less-desired colors to work around this problem hurts much more than the minor limit on the few rare tintable stamps. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] high-resolution stamps work now
On Wed, 2004-11-24 at 20:12, Bill Kendrick wrote: On Wed, Nov 24, 2004 at 05:11:03PM -0500, Albert Cahalan wrote: Unless someone objects, I'll add a feature request for this to the SF tracker. It seems complicated. :-( On the contrary. I like the idea of a slider over the Grow/Shrink (up-arrow/down-arrow) buttons we have now. Those buttons don't provide any feedback as to how big the stamp will be, just whether or not you can make it any smaller or bigger. (If you can't make it any bigger, you know it's the biggest... If you can't make it any smaller, you know it's the smallest... Otherwise, you have no idea what size it's set to.) My kid just looks at the outline. He does that as soon as he selects the stamp. He then presses the buttons and re-checks as needed to get the size right. I've been thinking that the audio could provide a hint. If you're at the limit, you just get a thump sound. If you're right before the limit, you get the regular swoop sound and then the thump. The swoop sound could change based on size. For example, there could be one octave from the minimum to the default, and another octave from there to the maximum. minimum: 200 Hz default: 400 Hz maximum: 800 Hz Sweep the appropriate fraction in 1/4 second, using a nice major chord sound. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] [PATCH] new tinter
To show off the new tinter, the enclosed patch restores
the original purple. Yellow is much, much, nicer with
this new tinter.
The one trouble is that pickup truck. It isn't anywhere
near constant hue. It varies from blue to green so much
that going plus-or-minus 25 degrees from the primary hue
is not enough. I could widen that up, but then I would
not be able to have tail lights and turn signals on a
green car remain unaffected by the tinting.
//
diff -Naurd t2/src/colors.h tx/src/colors.h
--- t2/src/colors.h 2004-11-22 20:28:45.0 -0500
+++ tx/src/colors.h 2004-11-25 00:18:52.0 -0500
@@ -52,7 +52,7 @@
{ 33, 148, 33}, /* Green */
{138, 168, 205}, /* Sky blue */
{ 0, 0, 255}, /* Blue */
- { 96, 0, 128}, /* Purple */
+ {128, 0, 128}, /* Purple */
{255, 0, 255}, /* Magenta */
{128, 96, 0}, /* Brown */
{226, 189, 166}, /* Tan */
diff -Naurd t2/src/tuxpaint.c tx/src/tuxpaint.c
--- t2/src/tuxpaint.c 2004-11-24 18:35:15.0 -0500
+++ tx/src/tuxpaint.c 2004-11-25 00:31:35.0 -0500
@@ -3009,58 +3009,266 @@
}
+//
+// stamp tinter
+
typedef struct multichan {
double r,g,b; // linear
double L,u,v; // L,a,b would be better -- 2-way formula unknown
double hue,sat;
- unsigned char or,og,ob,oa; // old 8-bit sRGB values
- unsigned char nr,ng,nb,na; // new 8-bit sRGB values
+ unsigned char or,og,ob; // old 8-bit sRGB values
+ unsigned char nr,ng,nb; // new 8-bit sRGB values
+ unsigned char alpha;// 8-bit alpha value
} multichan;
+#define X0 ((double)0.9505)
+#define Y0 ((double)1.)
+#define Z0 ((double)1.0890)
+#define u0_prime ( (4.0 * X0) / (X0 + 15.0*Y0 + 3.0*Z0) )
+#define v0_prime ( (9.0 * Y0) / (X0 + 15.0*Y0 + 3.0*Z0) )
+
+static void fill_multichan(multichan *mc)
+{
+ double tmp,X,Y,Z;
+ double u_prime, v_prime; /* temp, part of official formula */
+ double Y_norm, fract; /* severely temp */
+
+ // from 8-bit sRGB to linear RGB
+ tmp = mc-or / 255.0;
+ mc-r = (tmp=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+ tmp = mc-og / 255.0;
+ mc-g = (tmp=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+ tmp = mc-ob / 255.0;
+ mc-b = (tmp=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+
+ // coordinate change, RGB -- XYZ
+ X = 0.4124*mc-r + 0.3576*mc-g + 0.1805*mc-b;
+ Y = 0.2126*mc-r + 0.7152*mc-g + 0.0722*mc-b;
+ Z = 0.0193*mc-r + 0.1192*mc-g + 0.9505*mc-b;
+
+ // XYZ -- Luv
+ Y_norm = Y/Y0;
+ fract = 1.0 / (X + 15.0*Y + 3.0*Z);
+ u_prime = 4.0*X*fract;
+ v_prime = 9.0*Y*fract;
+ mc-L = (Y_norm0.008856) ? 116.0*pow(Y_norm,1.0/3.0)-16.0 : 903.3*Y_norm;
+ mc-u = 13.0*mc-L*(u_prime - u0_prime);
+ mc-v = 13.0*mc-L*(v_prime - v0_prime);
+
+ mc-sat = sqrt(mc-u*mc-u + mc-v*mc-v);
+ mc-hue = atan2(mc-u,mc-v);
+}
+
static void tint_surface(SDL_Surface * tmp_surf, SDL_Surface * surf_ptr)
{
+ unsigned i;
+ int xx, yy;
- float col_hue, col_sat, col_val,
-stamp_hue, stamp_sat, stamp_val;
+ unsigned width = surf_ptr-w;
+ unsigned height = surf_ptr-h;
- Uint8 r, g, b, a;
-int xx, yy;
+ multichan *work = malloc(sizeof *work * width * height);
- rgbtohsv(color_hexes[cur_color][0],
- color_hexes[cur_color][1],
- color_hexes[cur_color][2],
- col_hue, col_sat, col_val);
-
+ // put pixels into a more tolerable form
+ SDL_LockSurface(surf_ptr);
+ for (yy = 0; yy surf_ptr-h; yy++)
+{
+ for (xx = 0; xx surf_ptr-w; xx++)
+{
+ multichan *mc = work+yy*width+xx;
+ SDL_GetRGBA(getpixel(surf_ptr, xx, yy),
+ surf_ptr-format,
+ mc-or, mc-og, mc-ob, mc-alpha);
+}
+}
+ SDL_UnlockSurface(surf_ptr);
- /* Render the stamp: */
+ i = width * height;
+ while (i--)
+{
+ multichan *mc = work+i;
+ fill_multichan(mc);
+}
- SDL_LockSurface(surf_ptr);
- SDL_LockSurface(tmp_surf);
+ // initial hue guess
+ double alpha_total = 0;
+ double u_total = 0;
+ double v_total = 0;
+ i = width * height;
+ while (i--)
+{
+ multichan *mc = work+i;
+ alpha_total += mc-alpha;
+ // more weight to opaque high-saturation pixels
+ u_total += mc-alpha * mc-u * mc-sat;
+ v_total += mc-alpha * mc-v * mc-sat;
+}
+ double initial_hue = atan2(u_total,v_total);
- for (yy = 0; yy surf_ptr-h; yy++)
- {
- for (xx = 0; xx surf_ptr-w; xx++)
- {
- SDL_GetRGBA(getpixel(surf_ptr, xx, yy),
- surf_ptr-format,
- r, g, b, a);
-
- rgbtohsv(r, g, b, stamp_hue, stamp_sat, stamp_val);
-
- if ( stamp_tintgray(cur_stamp) || stamp_sat 0.25 )
- hsvtorgb(col_hue, col_sat, stamp_val, r, g, b);
- //else
- // hsvtorgb(col_hue, col_sat,
[Tuxpaint-dev] mouse movement bug
Here are two problems which might be the same bug. You may need a slow computer or large display to hit them. BTW, I have sound off right now. When placing a stamp, marks can get left on the screen. This is especially so if the mouse is moved quickly just prior to placing the stamp. When drawing a line, the end can remain undrawn. As the mouse moves, bits of the line are rendered. If the mouse is moved quickly, it can get ahead of the rendering. Then, if the mouse is suddenly stopped, there will be an unrendered gap next to the mouse pointer. The gap becomes permanent if the mouse button is released, but the gap is fixed if a tiny mouse movement is made. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] image usage terms
On Mon, 2004-11-22 at 16:27, Ben Armstrong wrote: On Mon, 2004-11-22 at 16:02 -0500, Albert Cahalan wrote: Are these terms acceptable for Tux Paint? http://gallery.hd.org/terms.html No. Redistribution is not allowed. Oh, duh. Somehow I missed that. I suppose I could ask for an exception. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] hu_HU.UTF-8
Why is it that this language alone does not set both LANGUAGE and LC_ALL in tuxpaint.c? Would it be harmful to set them both? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Sun, 2004-11-21 at 20:25, Mark K. Kim wrote: Turning on extra error messages sounds good. That's all you can turn on without... a. being gcc version-specific b. getting warnings for standard include files c. going insane :-) Regarding the last, there are a couple warnings that may look impossible to eliminate at first glance, but are not bad once you get what the concise message is all about. Adding static in places (default for C++, but not for C) will be helpful. -ffast-math should be okay, but it also turns on -funsafe-math-otpimizations which I'm kind of weary of... Any experts on this option? It's not really unsafe. :-) Normally, math is seriously slowed down by requirements related to the following: a. must set errno for sqrt(-5.2) and other bad math b. must not do algebraic optimization c. must cause SIGFLT signal in the right places Some people like to trap division by zero so that they can substitute in a correct value. Some people like to trap overflow so that they can fudge the exponent for greater range. There's no way Tux Paint will be doing this kind of thing. - COLOR_LIME, + COLOR_NEON, COLOR_GREEN, - COLOR_CYAN, + COLOR_SKYBLUE, COLOR_BLUE, COLOR_PURPLE, - COLOR_FUCHSIA, /* ... */ + COLOR_MAGENTA, COLOR_BROWN, - COLOR_GREY, - COLOR_SILVER, /* ... */ + COLOR_TAN, + COLOR_BEIGE, NUM_COLORS }; [snip] I like these color names better than the previously defined ones, but if we're going to change the names of the colors, let's use the canonical names, perhaps adopting the color names in /etc/X11/rgb.txt file. We may also have to retranslate the color names. I went for kid-friendly. I struggle to spell fuchsia. I asked my wife for an opinion, and she reports that a kid's toy and/or TV show (both I guess) uses magenta. A kid trying to pronounce fuchsia could get offensive. :-) The Sky blue is actually that now, computed as the average value of the sky in numerous images of the sky. (if you try this, remember to allow for gamma) Likewise, tan and beige were computed from many images. I don't care for silver, since it doesn't sparkle or gleam, but I figured light grey might be to difficult to read. BTW, both grey and gray are considered correct spellings. -#define MAX_STAMPS 256 +#define MAX_STAMPS 512 [snip] If we're gonna increase the stamps, is 512 enough? What's our stamps collection size? It'll do as an emergency fix. I hit the limit with about three dozen local stamps. [snip] #ifndef WIN32 - if (Mix_OpenAudio(44100, AUDIO_S16, 2, 1024) 0) + if (Mix_OpenAudio(44100, AUDIO_S16SYS, 2, 1024) 0) #else if (Mix_OpenAudio(44100, AUDIO_S16, 2, 2048) 0) #endif This change is for Mac, right? Does this change negatively affect Linux and/or BeOS (or Sun, etc.)? It should help more machines than it hurts. CPU soundcard notes LE LECommon PC. Unchanged. LE BEBroken before, and broken now. (rare) BE LEBroken now, but expected to be rare. BE BEMac. Now works, even if the drivers won't byteswap. It's rare to have a soundcard that only works with a byte order that is opposite to the CPU. I believe that the MacOS port will handle both; we'll see. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] rainbow tools
I think it would be good to have a tool, or tools, for drawing rainbows. For the primary rainbow, the inside angle is 80 degrees total (40+40) and the outside angle is 84 degrees. If we assume that a tuxpaint canvas has a 70-degree vertical field of view, same as used for popular FPS games, the rainbow size in pixels is determined. One might wish to draw a partial rainbow, and one might wish to place the horizon anywhere. So, trouble... The interface that comes to mind is that the user does a click-and-drag with rubber band effect to see where the rainbow will go. Constrain the second point to be within the diameter of the rainbow and not directly above or below the first point. Then there are exactly two circles passing through the two points, each divided into two arcs by the points. Eliminate the arcs that have an upside-down portion. This leaves one arc to be rendered as the rainbow. The next problem is endpoint treatment. They can be cut horizontally, but that is no good near the edges of the screen. Fading out is an option. Fading out is especially useful for realistic (as opposed to cartoon-like) rainbows. Cartoon-like rainbows have nicely distinct colors. In some ways though, they propagate a lie about how rainbows look. Realistic rainbows are beautiful and educational, but can be trouble. Going from inside to outside, you get: a. a bright area b. blue to red (40 to 42 degrees) bright primary bow c. a dark area d. red to blue (50 to 53 degrees) dim secondary bow e. slightly bright area When the Sun is low, you only see the yellow-red part. When the raindrops are big, the top is missing. (the drops are no longer spherical) When the drops are small, you get green and magenta bands just inside the primary bow. (caused by interference effects) I have the data I need to produce this. The problem of course is that the whole screen must be updated in order to get the light areas (a and e) right. This pretty much means that usage must be: 1. draw the background (sky,clouds,airplanes...) 2. add the rainbow 3. draw the foreground Thoughts? BTW, something involving spline paths also comes to mind. See the Inkscape write your name example in the tutorial, and imagine a rainbow rendered along the path. It wouldn't have the correct shape and size, but might be useful for art. (it's messy and near-useless for teaching about rainbows) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] TuxPaint 0.9.14 Mac OS X Build Available to Test
On Wed, 2004-11-10 at 12:56, Bill Kendrick wrote: On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote: Also, this isn't posted to this list because you've blocked non-subscribers. I wish you wouldn't do that. The [EMAIL PROTECTED] way is the right way. Well, if you want 95% spam on the list, sure, I can allow non-subscribers to post. :) I'm not seeing that on the [EMAIL PROTECTED] mailing list. I think I get about 1 spam per day. The list has been around for a while, and it has been mentioned all over: freshmeat.net, the procps web site, every release announcement, emails on linux-kernel, etc. The linux-kernel list gets a bit more, but not much. Just a couple spams per day make it past the filters, in a flood of 100 to 400 legitimate messages per day. Dropping HTML mail eliminates most of the spam. The positive benefits of an open list are huge. Bug reports can come in freely. Also, do NOT force replies to go to the list or not. Decent mailers provide both reply-tosender and reply-to-all (group reply) abilities; these must be left distinct to be useful. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] TuxPaint 0.9.14 Mac OS X Build Available to Test
On Wed, 2004-11-10 at 14:57, Bill Kendrick wrote: On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote: Quoting various people: 1. 'Starters' are broken, ... This is not only a MacOS problem. I get it too. Tuxpaint: from CVS yesterday OS: Debian-unstable with the 2.6.9-rc4 kernel Video: 24-bit (in 32-bit, AFAIK), w/ big display Hardware: Mac G4 Cube (yes, running Linux) So, while I'm not running MacOS, I do use a Mac. Odd features of the Mac hardware include: 1. big-endian 2. char is unsigned by default!!! 3. most (not all) audio hardware is big-endian only Hrm, okay, so this might be a clue as to what's going on. Unfortunately, without a Mac to debug on, I can't help here. I just tried compiling TuxPaint like this: make CC='gcc -fsigned-char' PREFIX=/usr There was no change. If starter images use some unusual feature of the SDL library, the problem could be in SDL. I suggest adding more warnings, like the ones used for procps: PKG_CFLAGS := -fno-common -ffast-math \ -W -Wall -Wshadow -Wcast-align -Wredundant-decls \ -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return \ -Wstrict-prototypes -Wmissing-prototypes Are you able to build with debugging printf()'s turned on? Do they provide any hints as to what's going on? I can build any way you like, but I wouldn't know what to look for. Nothing obvious stood out in a grep like this: egrep -i4 -- 'starters|-back' src/*[hc] | less -i BTW, the sound is messed up too. I just get static. Unfortunately, this is /not/ an issue on the latest Mac OS X build. Can you try altering the buffer size being set when the SDL sound system is first being initialized? Assuming you mean the last parameter to Mix_OpenAudio, I tried 8192, 2048, and 256. Sound is still bad. My sound goes through esd (Enlightenment sound daemon) to USB speakers. I don't think the USB speakers support more than one sampling rate. I can play MP3s just fine, the game Abuse works OK, the game SuperTux is staticy... ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] TuxPaint 0.9.14 Mac OS X Build Available to Test
On Wed, 2004-11-10 at 14:57, Bill Kendrick wrote: On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote: BTW, the sound is messed up too. I just get static. Unfortunately, this is /not/ an issue on the latest Mac OS X build. Can you try altering the buffer size being set when the SDL sound system is first being initialized? Using AUDIO_S16MSB fixes it: if (Mix_OpenAudio(44100, AUDIO_S16MSB, 2, 1024) 0) Now that I have sound working, I notice that latency is a problem. I can take the buffer size way down, but it doesn't help. (I tried 64) Maybe the sound files need to be trimmed. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
