Gimp Traffic #32 For 20 Feb 2001

There were 17 different contributors. 6 posted more than once. 9 posted last week too.

Hans Breuer posted some problems adapting make and export definition files for the WIN32 build of Gimp 1.3. The trouble arose with libgimpwidgets, where several functions needed to be linked against functions exported from Gimp.

Sven Neumann said the dependencies on the files looked right, and that the symbols should be exported, allowing Gimp to be linked against libgimpwidgets.

Hans said this had been done and that the problem was somewhere else. " The windoze version of gimpwidgefts can't include two symbols for different implementation of the same function. There is only one version of the dll in memory, even if loaded by another process. The code is shared across process boundaries while the data is not.It might be possible to build a sollution which detects at runtime, if the dll is loaded by gimp.exe and than dynamically resolve to symbols exported by gimp.exe. Otherwise the implementation querying the PDB would be used (this is what I tried to explain above). Obviously the PDB version does *not* work in the Gim process ..."

Nick Lamb suggested making two copies of the dlls, and linking one copy against libgimpwidgets and one against gimp.exe. Hans said this was the sort of thing he was trying to avoid, since the stuff in gimpwidgets was useful for other apps.

Michael Natterer mentioned that he planned to add a small libgimpglue library to solve some of the dependency problems. Michael(Mitch) thought that it was better to link the widgets statically into the WIN32 version of Gimp than to restructure the libraries.

Hans added " I've learned today, that this is a common feature of the ELF binaries, but on win32 the exporting library needs to be known at link time; or needs some additional coding ..." With that, Gimp 1.3 was running under WIN32.

Mitch closed by saying " It may look a bit strange to create a header-file-order dependency by not allowing includes in headers, but this only applies to stuff like "include system stuff before gimp stuff". The gimp includes itself can be ordered arbitratily. The benefit we get from this is that we can grep the sources to see which functions are used from where. We don't need to include something to get access to data types because they live in the "inter-module" namespace established by apptypes.h "

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 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).

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.

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.

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.

Simon Budig thought BrushApplicationHardness would be improved by adding directional modifiers. "This would be awfully cool."

Sven Neumann pointed out that gimp_context_get_texture had just disappeared from CVS. All data types are being migrated and will see major changes to the object hierarchy. He thought it was a very good idea, but one that should wait.

David thought that one mask was fine for finer textures like paper, and wondered if there was any benefit to storing [in the brush pipe file] multiple copies of a texture for differing amounts of pressure.

David suggested a definable pressure curve that could be applied to all tools. He thought that creating bitmaps for parameter values would lead to an exponential disaster. " For example: a 256x256 texture with 9 angles and 8 pressure levels will require more than 4 megs of memory."

Jens agreed on the exponential disaster. He also suggested the generation of brushes, so that the pixmaps would be a function of the brush.

Daniel Egger thought a definable pressure curve could be gathered from a lookup table rather than having to talk to the driver. He also thought the exponential disaster of these type of brushes was overstated, since it was optional.

Sven Neumann added that Gimp holds all patterns and brushes in memory regardless if they are ever used. " This is one of the main points why I'm asking for spending some thoughts about a better data system for The GIMP before adding just another data type like textures. "

Sven Neumann pointed to FANCY_PRESSURE as an existing (though #ifdefed out) implementation of sophisticated pressure curves. He thought that two mechanisms needed to be considered: a cache, and a method for paint_core to pull out different data from the same object depending on the parameters.

Daniel Egger thought that fine grained control of the pressure curve was a great idea, and that it should be definable by tool, as well as across the entire application.

Jens Lautenbacher, at the request of and with aid from Sven, posted his RFC on the concept of PaintObjects.

... Therefore I propose to completely rewrite everything that can be considered a "PaintObject" into a generic provider form, where the paintcore for each operation asks the provider for it's data.

E.g. a brush pipe is a provider that gives back a tempbuf of grayscale data (a brush) or a pixmap brush when asked for it.

Besides providers that give back pixmap data, there will be scalar providers, which can be used for example to return color values. Painting with the color selected from a gradient will be just using a color provider object, that uses a gradient as it's LUT for color values.

All the providers will get as an input parameter the current global state of the input device, so all providers will be able to select matching output data much the same way the current pipe does.

As David already pointed out, it doesn't make sense to only provide for the possibility for a pipe to select from a fixed set of pregenerated pixmaps. this is nice for the current limited pipe, but when using a general pipe as a provider for textures/patterns/brushes one wants to have the possibility to match certain or all dimensions of the data space to a function.

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.

For performance reasons, all ProviderObjects should automatically have a LRU Cache (or some tuned variant of it) to store already computed values. This of course can be handled in a base class for them, so implementing another provider doesn't need the programmer to cope with this anymore.

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 think that a user wishing to use a brush as a pattern can always load the brushfile in the gimp, and save it as a pattern (remember that we talk about general pipes here already: laoding a brush and saving it as a pattern will result in a pattern that changes according to the input state in the same way as the original brush does.)

[...]

All of these providers should fulfill another contract with some ViewContainers so they are able to draw representations of themself into such a container. As far as I understood Sven, Mitch already has some kind of a GimpViewable object and a general container type to handle them. My suggestion goes along the line that this functionality should be put into the same object as the PaintProvider, so one object is able to do the work it's supposed to do AND draw it's representation to the screen.

Jens went on to add that a good interface would be needed for multidimensional providers.

So would this mean one could have something like multilayer XCF files as patterns, that "dig in" the layerstack if one uses more pressure? This would be pretty awesome. The "Tommer" example comes to mind first: Have something like this:

Layer 1: skin pattern
Layer 2: some red goo
Layer 3: some tissue layers
Layer 4: guts and stuff
Layer 5: rib bones or something

Yes. This is a gross example, but it demonstrates the idea pretty well. So then you can draw "wounds" to a image, and depending on your pen pressure you get different stuff. Maybe I am on crack with this, who knows. But it doesnt sound like too impossible. Then the brush shape could be used as a transparency mask when composing the strokes together.

David A. Bartold didn't think that a texture would need to be modified by pressure since the pressure modifies the brush mask. It did add interesting possibilities with tilt and stroke angle, since the texture could act as a bumpmap to modify the results, allowing the stroke direction to deposit more pigment on the facing high points of the stroke.

Adrian Likins thought it was a powerful idea, but warned that the interface could end up being as non intuitive as analog synths: " ...where you have this dozen input sources, and a dozen filters, and a dosen places to hook them to. Lots of power there. Of course, this is far from a intuitive interface. If your've ever played with an old analog synth and spent 20 minutes making it go "swoooooooshhhhhhhhhhhhhkkkakkkkkkkkkckakkcakkkkcacaaaoooooooooo" before, and then actually try to make useful sounds with it, you knwo what I mean. "

Austin Donnelly thought it would be nice to allow loadable modules to implement new providers. This would make a nice harness for playing with watercolor simulators. pixel fairy suggested that this would also be useful for three dimensional paint surfaces, where a bump map defines the texture of the surface, rather than defining the texture in the brush.

Jens Lautenbacher wanted to know how all of this affected the PaintCore. He thought paint core should be a dumb as possible and focus only on painting something. " E.g. is painting with a pattern not just a provider that hands out pixmap brushes that change with the movement? Or is this too fas stretched? Even if it is too far stretched for this example, the general benefit may be worth it. I dunno."

Frank de Lange posted a question relating to fonts. " It does not matter whether I try Type1 or TrueType fonts, the effect stays the same. Text Tool presents me with all the fonts available to my X server, but fails to find them when the time comes to render them into the image. On similar-sized blank images it `just works'. There does not seem to be any relation between the size of the image and the appearance of this bug. Changing the image from RGB to greyscale or indexed does not change the behavior. Nor does resizing, scaling or otherwise manipulating the image. Nor does making a duplicate and trying to add the text to the duplicate (same effect, `font not found'). Selecting the entire image. copying it and pasting it as new does not change the effect ('font not found'). In short, NOTHING works. But the same font, on a different image, JUST WORKS. "

Austin Donnelly commented that selecting a particular "Point Size" will scale the text so that it comes out at the image's resolution. Using "Pixels" will probably give the desired effect. For new images, the resolution is similar to that of the screen, so the difference between points and pixels is minor.

Michael Natterer added that if the resolution is extreme, then the Gimp requests really huge fonts, causing some X font servers to crash

Roel Schroeven asked why logarithmic scaling in histograms was used, and not linear. Austin Donnelly mentioned that it had been that way since Jay Cox included it in the initial CVS revision of the Gimp. Jay Cox then posted that the log histogram was around before he had heard of the Gimp, and that he just made it a widget. Jay thought it was around from the days of Spencer and Peter. He suggested that Linear, Log, and sqrt are all common ways to scale histograms and that they could be an option in preferences. Austin said he would play with that idea.

Nick Lamb wanted to know if anyone else had noticed that channel previews had been broken in CVS HEAD for a couple of weeks Sven Neumann said that Mitch was generalizing the preview code and that it would work (and work better) when that was in place

Ernst Lippe wanted to know the best way to handle errors from a plug-in to a user. Sven Neumann said to use g_message(). It would do the right thing if the plug-in is run from the console or from within the Gimp.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	4 Feb 2001 - 6 Feb 2001	(8 posts)	Gimp 1.3 Windows Compile and Link Dependencies
2.	5 Feb 2001 - 17 Feb 2001	(14 posts)	Proposed Paint Core Changes
3.	9 Feb 2001	(6 posts)	PaintObjects
4.	8 Feb 2001 - 9 Feb 2001	(4 posts)	Font Problems
5.	4 Feb 2001 - 8 Feb 2001	(5 posts)	Logarithmic Histogram
6.	13 Feb 2001	(2 posts)	Channel Previews in CVS Head
7.	13 Feb 2001	(2 posts)	Handling Error Messages in Plug-Ins

Gimp Traffic #32 For 20 Feb 2001

By Cris Flagg