Re: RFC: unified system of "PaintObjects" (long)
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
Re: Proposed Paint Core changes to support textures
On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote: > > > The major problem with having different texture maps for each pressure > > is the amount of memory necessary to store them. Texture tiles > > ... > > But you can have different effects if you have the choice to use > pressure-mapped-brushes as song as we don't have mathematical brushes > because some tools (in reallife) behave quite differently when one applies > bigger pressure to them. I agree completely to supporting changing the texture bitmap depending on pressure. At the time I wrote the last email, I could not think of a practical use for it. Today I had a burst of inspiration: it could be used to simulate table texture beneath paper. The higher the pressure, the more the table shows through. Of course, you could also use other more exciting textures underneath: coins, leaves, grass, wicker, etc. Such textures would be great for pencil-rubbed backgrounds. In general a texture will not be modified by pressure. Textures normally don't deform due to greater applied pressure (barring the simulation of actually destroying the medium!) What does change is the amount of pressure exerted by the brush at all points of contact. GIMP already accounts for these changes by modifying the brush mask (its hardness, size, and opacity).* What is unclear at this point is how to generalize the texture composition function. It has two parameters, brush mask and texture, and returns a new brush mask. A good composition function for crayons, pencils, chalk, and pastels is subtraction using saturation arithmetic.** A potentially useful function for some types of media (which ones???) is the multiplication function. There may be other composition operators that specifically address certain drawing implements. - David * Technically, The GIMP does not modify the brush mask's opacity by pressure. It optimizes the operation by multiplying the stylus pressure (treated as an opacity) by the tool's opacity hscale. It then passes that new value to the paste_brush function. This optimization needs to be disabled when a texture is used, since the two opacities have different semantics. ** Saturation subtraction is based on the fact that drawing with a pencil lightly will not fill the paper's pits no matter how many times one goes over the same spot. Multiplication could simulate the amount of ink deposited from a marker, pits get more ink than peaks.
Re: Proposed Paint Core changes to support textures
> > deeper crevases of the texture. Is there a practical benefit for storing > > multiple copies of a texture for differing amounts of pressure inside a > > brush pipe file? > > yes. a) not another special case > > b) you can easily implement any function between pressure and > change-in-texture without changing the core > > c) not another special case. I think a better solution would be a definable pressure curve, much like Wacom's Windows driver has. That'd probably be a feature of the general mechanism you described and perhaps what you have in mind. A user (or a brush designer) can define their own function and the mechanism would be usable for all tools, not just ones that draw by copying from bitmaps. The major problem with having different texture maps for each pressure is the amount of memory necessary to store them. Texture tiles generally are much bigger than brushes to reduce visible repetition. A texture of size 256x256 is not uncommon, and if there were 8 copies of that texture stored in a brush pipe file, each bitmap corresponding to a different pressure, then the file will be ~500k. That's a big download (and a lot of cache misses) just for one texture. Since many people download their copies of GIMP, that's a lot of bandwidth, too. I'm not convinced creating bitmaps specific to certain values of parameter subsets (such as angle, pressure, velocity, random, ordering, etc) is really the proper solution. It works okay if you want to change a tool depending on the value of one variable, but each time a parameter is added, the number of bitmaps increases manyfold. Basically the whole mechanism explodes in an exponential disaster. ;) For example: a 256x256 texture with 9 angles and 8 pressure levels will require more than 4 megs of memory. - David
Re: Proposed Paint Core changes to support textures
The brush pipe idea sounds interesting as it'd support tilt. That'd be useful for modelling textures that have larger features than the tool size. I could see the benefit there for simulating drawing on corrugated cardboard. For finer textures (i.e. paper) one mask is fine. The texture code would modify the brush mask at runtime using the current texture and pressure. Higher pressure desposits more pigment into the deeper crevases of the texture. Is there a practical benefit for storing multiple copies of a texture for differing amounts of pressure inside a brush pipe file? - David On 6 Feb 2001, Jens Lautenbacher wrote: > "David A. Bartold" <[EMAIL PROTECTED]> writes: > > > I dug into the paint core to see what needs to be changed to support > > drawing on textured media. Here's the basic modifications necessary: > > > > * enum BrushApplicationHardness: > > Add a new value "TEXTURE" which applies both pressure and > > texture to a brush mask. It doesn't make sense to apply > > only texture. Rationale: much of the realism afforded by > > textures is due to the interaction between them and the > > pressure an artist exerts on the medium. > > I don't know how your stuff will work, and how you "apply pressure" in > your code. but, as I wrote in my other post, using a brushpipe for the > textures would maybe help with this, too as you could use changing > textures with regard to the pressure applied (or e.g. tilt) > > jtl >
configure.in/Makefile.am diffs + Tiles
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
Proposed Paint Core changes to support textures
I dug into the paint core to see what needs to be changed to support drawing on textured media. Here's the basic modifications necessary: * enum BrushApplicationHardness: Add a new value "TEXTURE" which applies both pressure and texture to a brush mask. It doesn't make sense to apply only texture. Rationale: much of the realism afforded by textures is due to the interaction between them and the pressure an artist exerts on the medium. * function paint_core_get_brush_mask: Add "TEXTURE" to the switch statement. It will call the function paint_core_texturize_mask (mask, x, y, pressure). * new function paint_core_texturize_mask: Calls paint_core_pressurize_mask. Next, it calls gimp_context_get_texture (). Last, it applies the texturing algorithm described in the previous email using the x and y arguments as an offset into the texture. * new function gimp_context_get_texture: Returns a GPattern * from the specified context. Heeding Seth's advice not to create a new file format without good reason, I've determined the .PAT format to be suitable for this purpose: it supports grayscale data and description text. Also, it provides an already existing API framework, GPattern. I have Makefile.am and configure.in modifications for a new textures directory. Also, I have some texture tiles that may be added to the new directory. The autoconf/automake diffs will be sent in a seperate email along with a pointer to the new tiles. - David
Re: Proposal for a texture selector
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
Proposal for a texture selector
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: some special effects
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
Re: ANNOUNCE: Realistic media plug-in for the GIMP v1.2
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 >
ANNOUNCE: Realistic media plug-in for the GIMP v1.2
I am pleased to announce a new plug-in that provides GIMP users with a realistic color pencil tool. Given a pressure-sensitive graphics tablet, it looks and feels like a real artist's pencil. You can also use a mouse if you'd like. The plug-in provides two new menu items: /Media/Texture... and /Media/Color Pencils The "Texture" item will let you select from a few common paper textures and then generates a texture channel for your image. You can also generate your own textures using the standard GIMP tools/filters. The "Color Pencils" item will pop up a new window that will let you draw and erase as desired. Once you have the image the way you want, you can hit the "OK" button and the image will be updated in The GIMP. The webpage (and source code) for this plug-in is at: http://uts.cc.utexas.edu/~foxx/digipencil/ Note that this is development-stage code, so please let me know if you discover any bugs. Enjoy, David A. Bartold
