Re: ANNOUNCE: Realistic media plug-in for the GIMP v1.2

2001-02-01 Thread David A. Bartold

Yes, that is also one of the things I wanted to add first, not only
for more colors but to save screen space and provide the user with a
visual indication of which colors are active.  I coded up a
color display that shows the colors much like the way The GIMP does,
and the user may change the foreground/background by clicking on the
swatch to pop up a color picker window.  The new code is available for
you to download on the website as phymodmedia-0.4.1.tgz.

- David

On Wed, 31 Jan 2001, Rebecca J. Walter wrote:

 looks pretty cool, but it would be nice to have full control over
 color.  perhaps that would be a future upgrade to it?
 bex
 




Re: some special effects

2001-02-01 Thread David A. Bartold

A good place to start is the Writing a GIMP Plug-In documentation:
  http://gimp-plug-ins.sourceforge.net/doc/Writing/

Once you get the basic idea how plug-ins work and come up with an
algorithm you wish to implement, it helps to take the source code from a
simple plug-in, i.e. blur, and replace the algorithm and plug-in
information with your own.

- David

On Thu, 1 Feb 2001, Image Processing wrote:

 Hi, I am learning image proceesing nowadays. And I find that GIMP is really a nice 
place to visit. 
 
 I have several questions. I like to implement some special effects by myself, such 
as 'Colored Pencil', 'Chalk  Charcoal' in Adobe Photoshop. But I don't know how to 
do. Could anybody give me some advice about how to do? Thanks a lot!
 
 Best Regards,
 
 Bam




Proposal for a texture selector

2001-02-03 Thread David A. Bartold

There needs to be a way to select a texture before advanced tools can
be added to The GIMP.  I propose to create a new dialog box similar
to the pattern selector.  Instead of containing tilable RGB pixmaps, it
will contain tileable greyscale heightfield pixmaps.  These textures will
be used by some tools to simulate, for example, paper grain.

The user can see the current texture in the main window and in the
Device status window.  It will be near the current brush selection,
pattern, and gradient.

A mock-up "screenshot" is available here:
http://uts.cc.utexas.edu/~foxx/texture_sel.png

I'm not too happy about making the gradient a square rather than a
rectangle.  The brush, pattern, and texture could be horizontally
adjacent and the gradient placed underneath all three.  I.e.:
 ___   ___   ___
|   | |   | |   |
|___| |___| |___|
 ___
|   |
|___|

Anybody else have a suggestion?

There will need to be a new file format for the textures, however
the code can easily be borrowed from the .pat or .gbr plug-ins.  The
extension could be .gtx for GIMP Texture (assuming that extention isn't
used).

- David




Re: Proposal for a texture selector

2001-02-04 Thread David A. Bartold

See below-

On 4 Feb 2001, Sven Neumann wrote:

  There needs to be a way to select a texture before advanced tools can
  be added to The GIMP.  I propose to create a new dialog box similar
  to the pattern selector.  Instead of containing tilable RGB pixmaps, it
  will contain tileable greyscale heightfield pixmaps.  These textures will
  be used by some tools to simulate, for example, paper grain.



 Sounds like a reasonable idea if and only if we make almost all paint tools
 use this texture. Are there any algorithms which have proven to fit into
 the Gimp paint_core?

I haven't poked into the paint_core too deeply, however here's an
algorithm that should be easy to integrate:  Subtract the texture
from the already subpixel and pressure adjusted brush mask, clipping below
at zero.  Use the results as the new mask.  Basically the arithmetic looks
like this, assuming a mask value of zero means no composition and a
texture value of 0 represents the highest peak:

new_mask[x][y] = MAX (mask[x][y] - texture[x + offset_x][y + offset_y], 0)

If you set wax = 0% and opacity = 100% in DigiPencil, you will see
the effect described by the above algorithm.

 Before you think about writing code, we are are designing an abstract 
 GimpData object at the moment which will be the parent of all those brush,
 pattern, gradient, ... stuff. Those data objects will go into a GimpContainer
 (which has just appeared in CVS) which will handle the problems of keeping
 names unique, etc. We will also provide views on these objects so all data
 previews and all sort of brush, pattern, gradient, ... -dialogs can reuse
 the same code. 

Very cool, that should simplify the process of creating a texture selector
greatly.  In addition to providing UI elements for the user, there also
needs to be an API for scripts and the plug-ins to change the texture.

Thanks for the input,
David




configure.in/Makefile.am diffs + Tiles

2001-02-05 Thread David A. Bartold

Regarding the previous email, it seems some tools call the brush paint
function with either SOFT or PRESSURE depending on the value of a boolean
variable.  I'm not quite sure what's the difference between the two,
however, it looks like it might be better to add a boolean parameter to
the paint_core_get_brush_mask function instead of adding a TEXTURE option
to BrushApplicationHardness.  That way, a get_brush_mask call can use any 
of the operations and also optionally apply the current texture to the
mask.

Here's the changes made to supply a textures directory.  The tiles are
available at: http://uts.cc.utexas.edu/~foxx/textures/

For configure.in:

 patterndata=`ls -1 $srcdir/data/patterns | grep -v Makefile`
+texturedata=`ls -1 $srcdir/data/textures | grep -v Makefile`

 patterndata=`echo $patterndata`
+texturedata=`echo $texturedata`

 AC_SUBST(patterndata)
+AC_SUBST(texturedata)

 data/patterns/Makefile
+data/textures/Makefile


For data/Makefile.am:

-SUBDIRS = brushes gradients palettes patterns
+SUBDIRS = brushes gradients palettes patterns textures

 patterndata=
+texturedata=


For data/brushes, data/gradients, data/palettes, data/patterns:

 patterndata =
+texturedata =

New data/textures/Makefile.am:

texturedatadir = $(gimpdatadir)/textures

brushdata =
gradientdata =
palettedata =
patterndata =
texturedata =

texturedata_DATA = @texturedata@

EXTRA_DIST = $(texturedata_DATA)

.PHONY: files

FILES = \
cloth.pat   \
heavy_paper.pat \
light_paper.pat \
medium_paper.pat\
tiles.pat





Re: RFC: unified system of PaintObjects (long)

2001-02-09 Thread David A. Bartold

On 9 Feb 2001, Jens Lautenbacher wrote:

 Here the question naturally arises: what kind of functions should be
 possible? Only transformations? Only some set of functions that are
 predefined in the core? Or could there be some possibility to handle
 user provided functions? How would these (if possible) be specified in
 a fileformat? or just LUTs that are used by functionality that is
 special to the object (e.g. for textures, there needs to be some
 special functionality on how to map the input state (mainly pressure I
 assume) to the final buffer returned. Here a LUT or a simply scalar
 function seems to be the way to go.

Those are good questions.  A texture won't need to be modified by pressure
in most cases since pressure modifies the brush mask.  However, if tilt
and/or stroke angle is available to the PaintObject, a texture 
theoretically could be mathematically modified by bumpmapping it.  The
stroke angle becomes the bumpmap light source azimuth and perhaps then the
resulting bumpmap is multiplied by the original texture.  Then the
tilt can be used as a reinforcement.  That way high points facing the
direction of the stroke get more deposited pigment.

The texture stuff probably wouldn't benefit from user functions.  Having 
one or two good built-in defaults ought to be good.

If user supplied functions were supported, it'd seem they would need to be
compiled if they work on pixels.  If they are used for defining transform
matrices, then they could be interpreted in Scheme.

 Another thing that should be really well thought about is how far this
 abstraction is presented to the user. Having all of the paintobjects
 fulfill a generic interface w.r.t the paintcore it makes it possible
 to e.g. use a texture as a brush and vice versa. I would still
 strongly argue against presenting such a possibility to the user. From
 his/her point of view, a brush is NOT a pattern, nor a texture. 

I'd agree with this.  If for some odd reason a creative user wishes to
use a texture as a pattern, then he/she can save a copy as a
pattern.  If there is one file format for patterns/brushes/texture/etc
they could even copy or soft link as needed.

- David