Thread: Re: [Tuxpaint-devel] tinter broken
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
|
From: Albert C. <aca...@gm...> - 2006-03-13 00:12:57
|
> I recently extracted the "Extending Tux Paint" section from the README > (which covers the creation of brushes, stamps, starters, etc.), and notic= ed > that (1) it still mentions "tintnogrey" which I guess you removed a long > time ago, and (2) it does NOT mention the "tinter=3D..." options. I can't find the README at all, but the tinter seems to work. :-/ > It seems that the "tinter=3D" option in stamp .dat files is not working. > I added a few printf() lines for debugging, and see a lot of NAN values > being thrown around. It always seems to default to 'vector' tinting mode > because of this. > > Albert, can you look into this for me, since you wrote it (and I haven't > the vaguest idea where to begin!)? I pick the race car. I choose a color. The red parts of the car change to that color. The non-red parts remain as they were. That includes the yellow on the helmet, the black tires, the grey wheels, and the white paint up top. You don't get the same thing??? FYI, I'm using a CPU with floating-point math like this: * no built-in trig functions * true 32-bit float * true 64-bit double * no 80-bit long double (uses 64-bit) You probably have: * built-in trig functions * 32-bit float done via 80-bit intermediate * 64-bit double done via 80-bit intermediate * true 80-bit long double To make your computer more like mine for testing purposes, try the compiler options to use sse3 for floating-point. (if your CPU can run such code) You can also try replacing -ffast-math with -ffloat-store. (these options might slow things down, but might help for debugging) > Additionally, I was wondering if you'd be willing to describe what, exact= ly, > the different tinter modes actually do, and when one would be more suitab= le > than others. (Since it's broken right now, I can't even observe what > the differences might be!) narrow: tint a narrow hue angle normal: tint a normal hue angle anyhue: tint a 360-degree hue angle vector: make greyscale, then black=3Dblack and white=3Dselected Vector is only good for cartoons that are specifically designed to work with it, as a number of the older stamps were. The other modes exist, sadly, because real-world colored objects are not purely a single hue. For example, the pickup truck stamp varies from blue to green. Choosing a wide hue angle will allow tinting to work without leaving untinted spots. That same wide hue angle applied to the race car would probably tint the yellow spot on the driver's helmet by mistake. Since "hue angle" isn't an exact concept, I'd rather not have a number given in the documentation. Tools disagree greatly. I think people should just use tinter=3Dnormal unless there is a visible problem. There are other ways to deal with things. Suppose you wanted to make the pickup truck more tint-friendly. Open it in the gimp. Using the color picker with a window size that just barely fits on the blue-green part of the truck, pick the color. Set the painting mode to "hue only" and paint the truck. Alternately, you could select the colored part and then run some sort of filter. |
|
From: Bill K. <nb...@so...> - 2006-03-13 00:34:10
|
On Sun, Mar 12, 2006 at 07:12:54PM -0500, Albert Cahalan wrote: > > I recently extracted the "Extending Tux Paint" section from the README > > (which covers the creation of brushes, stamps, starters, etc.), and noticed > > that (1) it still mentions "tintnogrey" which I guess you removed a long > > time ago, and (2) it does NOT mention the "tinter=..." options. > > I can't find the README at all, but the tinter seems to work. :-/ FYI, the "Extending Tux Paint" section in README has been broken into a new file, EXTENDING. They are HTML files living in "docs/html", and a Makefile in "docs" can be used to generate the plaintext versions that live in "docs/". (It uses an invocation of "links -dump" to do this.) > I pick the race car. I choose a color. The red parts of the car change > to that color. The non-red parts remain as they were. That includes > the yellow on the helmet, the black tires, the grey wheels, and the > white paint up top. Comes out pretty badly for me. :^/ Black comes out solid black, for example. > You don't get the same thing??? See: http://www.sonic.net/~nbs/20060312162357.png > FYI, I'm using a CPU with floating-point math like this: <snip> > To make your computer more like mine for testing purposes, try the > compiler options to use sse3 for floating-point. (if your CPU can run > such code) You can also try replacing -ffast-math with -ffloat-store. > (these options might slow things down, but might help for debugging) Ah-hah! That did it! See: http://www.sonic.net/~nbs/20060312162748.png I guess for now I'll use "-ffloat-store" in the CFLAGS...? (FYI, that pict. looks darker when I view with something like "xview", and looks better inside Tux Paint, GIMP or Konqueror. Xview being lame about PNG gamma?) > narrow: tint a narrow hue angle > normal: tint a normal hue angle > anyhue: tint a 360-degree hue angle > > vector: make greyscale, then black=black and white=selected <snip> Thanks! I'll try to incorporate this into the docs. -bill! |