Gimp Traffic #29 For 29 Jan 2001

By Cris Flagg

The GIMP Homepage (http://www.gimp.org) | The GIMP News Archive (http://www.xach.com/gimp/news/index.html) | The GIMP Mailing Lists (http://www.gimp.org/mailing_list.html) | The GIMP FAQ (http://www.rru.com/~meo/gimp/)

Table Of Contents

1. FreeImage

14 Jan 2001 - 15 Jan 2001 (4 posts) Archive Link: "FreeImage"

People: Raphael Quinet, , Martin Weber

Martin Weber asked about the use of FreeImage (located at http://home.wxs.nl/~flvdberg/) with the Gimp. Lourens Veen wanted to know if it was GPL compatible or if it would work with the current plugin system. Martin said it didn't have a plugin interface.

Raphael Quinet took a look at the FreeImage license and didn't think it was compatible. He said:

The spirit of this license is similar to the GPL, except that it has some sections specifically addressing the patents that could protect this code. Some things make me think that it could have problems with the GPL:

  1. The sections on patents. It specifically states in sections 2.1.b, 2.2.b and 3.4 that the initial developer (Floris van den Berg) or other contributors may have current or future patents on the algorithms or interfaces used in the program. The rights granted on these patents are granted "solely to the extent that any such patent is reasonably necessary to enable You to Utilize the [code] and not to any greater extent that may be necessary to Utilize further Modifications or combinations." This is probably not compatible with the GPL, which forbids you to include any discriminations against the free usage of the code.
  2. Section 3.1 states that "You may not offer or impose any terms on any Source Code version that alters or restricts the applicable version of this License or the recipients' rights hereunder." This basically prevents you from changing the license, and I think that some parts of the GPL could be considered as additional restrictions.
  3. In section 3.2, the minimum amount of time during which the source code must be offered to anybody who did not get it together with the binaries is shorter than the one required by the GPL.
  4. The indemnification clause in section 3.6 seems suspicious to me, and contrary to the "no warranty" of the GPL.
  5. Section 3.7 is similar to the virus-like feature of the GPL: the license must be applied to any larger work containing the covered code. Since both the GPL and the FreeImage license state that all of their requirements must be fulfilled by any package including the covered code, and since these licenses seem to have incompatible requirements, I doubt that we can use any of the FreeImage code.

So I think that we have no other choice than to stay away from the FreeImage code. Especially if any part of it is covered by some patents. In that case, we should not even look at the code, in order to be sure that we are not involuntarily including any patented stuff in the Gimp.

Unless someone who is more qualified than me in legal matters can certify that the FreeImage license is GPL-compatible, we should not use any part of it.

2. Update CVS Autoconf, Automake, Libtool

19 Jan 2001 (1 post) Archive Link: "interesting project: update to cvs autoconf,automake,libtool"

People: Daniel R Risacher, 

Daniel R. Risacher posted, "I just updated to the cvs versions of gimp, autoconf, automake and libtool. Gimp abjectly fails to build with the CVS versions of the build tools. An enterprising developer wishing to earn fame and glory might hack on this and figure out what the hell has changed in the auto-tools, and what would need to be done for the gimp to make it build with them."

3. Using Two Mice

20 Jan 2001 (3 posts) Archive Link: "Using two mice"

People: Nick Lamb, , Michael Natterer, Marc Lehmann

Nick Lamb posted that he thought there would be advantages to using two mice with the Gimp. He pointed out that with AlwaysCore and Xinput enabled, the Gimp's behavior breaks down. This could be due to GTK+ / XFree. He said the Gimp "can no longer properly detect the core cursor (you can't draw with it) and the additional mouse seems to always generate mouse down events at the origin, making it quite unusable." He wanted to know if anyone else had successfully got this to work.

Michael Natterer said he had used this setup with gdisp_shell. He has the mouse (right hand) configured to generate core events and a wacom tablet (left hand) _not_ generating core events and set to "window" mode.

Marc Lehmann mentioned that some cool effects could be generated with two wacom pens at the same time.

There were no more posts in this thread

4. ANNOUNCE Gimp-Print 4.1.2

21 Jan 2001 (1 post) Archive Link: "ANNOUNCE Gimp-Print 4.1.2"

People: Robert L Krawitz, 

Robert L Krawitz posted:

All users of the Epson driver should take this release, particularly if you've had problems with the very bottom of the print not printing out and the page not ejecting (this is accompanied by a segmentation violation if it happens).

The next release of gimp-print will include a major reorganization that puts it more in line with GNU packaging standards. This is a somewhat emergency release because of large numbers of reports of problems with 4.1.1.

Print 4.1.2 contains the following fixes and improvements over 4.1.1:

  1. We believe this release contains an important bug fix that in some cases caused the Epson driver to seg fault upon completion. This resulted in the page being slightly incomplete at the bottom, and in addition the page was not ejected.
  2. Further improvements in quality (we believe) in Photograph mode.
  3. Correct sizing for extremely tiny images in the Print plugin.
  4. First cut at roll feed printing for the Epson Stylus Photo 870/1270.
  5. Support for custom paper sizes in the Print plugin.
  6. Initial support for the Lexmark 3200, and other improvements in the Lexmark driver.
  7. Preliminary support for the Epson Stylus Photo 790/890/1290 (followons to the 870/1270).
  8. Fixes to the Debian installation.
  9. Preliminary support for the Canon BJC-55 and BJC-85.
  10. The Ghostscript Makefile snippets now contain a proper dependency on gdevstp-print.h.
  11. Many internal changes to prepare for a major code reorganization that is coming up shortly. These changes should be completely invisible at user level.

5. Denoise, Despeckle Revisited

16 Jan 2001 (1 post) Archive Link: "Denoise"

People: Martin Weber, 

This post was in regards to the discussion on Despeckling last week. Martin Weber posted:

I have a code for despeckling images that is based on Sethian's idea to filter out noise by using Min/Max Curvature. Currently all color channels are treated independently. This does not lead to very good results. Perhaps someone could overcome this problem and also improve the rest of the code.

He posted the source code, located at http://www.mail-archive.com/gimp-developer%40scam.xcf.berkeley.edu/msg03971/denoise.tgz

6. Tiled View

23 Jan 2001 - 26 Jan 2001 (8 posts) Archive Link: "tiled view"

People: , Nick Lamb, Mattias Engdegard

Mirar requested a feature for the Gimp"

Doing tiled images for textures used in 3d worlds, the best method I've found out isn't very good, it's the procedure of:

  1. make an image the right size that looks tiled
  2. tile it 2x2
    1. did it tile? finished!
  3. fix the things that didn't tile
  4. crop the center of it to the right size
  5. repeat from 2
This procedure isn't that fun. I want a tiled view mode, which shouldn't be too hard to do considering the view modes already handle things as scale and scroll.

I made a mockup to express what I mean, http://www.mirar.org/incoming/gimp_tiled_view.jpeg (http://www.mirar.org/incoming/gimp_tiled_view.jpeg)

ie, it should be able to do two things; First, just redraw the image tiled all over the view window. Second, it should be able to do draw operations tiled over the borders of the image (and layer), so you actually can work in this mode too.

Nick Lamb suggested "

  1. Draw first attempt at tile
  2. Image->Transforms->Offset
    1. Hit Offset by x/2 y/2 etc.
  3. Fiddle with any edges revealed by this
Adding a special mode to Gimp seems like overkill to me, but hey - it's a popular request and all patches will be considered. " Mattias Engdegard thought Nick's procedure would only help with the local edge transition and didn't give any overview to reveal any disturbing salient patterns. He also thought this might be a good idea for the Gimp, but it would need to be thought out carefully.

Mirar suggested applying the current operation on the x+Tx*i,y+Tx*i position too, and skip the tiled view. Mattias Engdegard thought this approach was harder since all ops have to be replicated that way, including filters. " On the other hand, having brushes work modulo the image size might be handy, but is perhaps orthogonal to having a tiled view mode. Having a tiled view in 100% scale while editing the same image in a magnified window would be very handy when making tiles. But this could be implemented more generally by having a view constructed procedurally by a script --- perhaps trigged by an event mechanism, activated each time the view needs re-rendering. Preferably this should happen in the background to minimize interactive latency for the user. This would give the Gimp some of the what-if capability of spreadsheets. You work in one window as usual, and another window dynamically displays the results of certain transforms applied to the first image. This can be tiling, filters, combinations of other images etc. I can not only see the tile repeated next to itself, but also how it combines with other tiles "

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.