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
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
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: 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
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
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