LWN.net Weekly Edition for March 25, 2004

The Grumpy Editor's Guide to Image Viewers

Your editor is a firm believer in the advantages of free software. As such, he takes great pride in running a desktop system with nothing but free applications on it. Thanks to countless developers who have released their work under a free license, there is no need to run non-free software, and that fact makes a grumpy editor a little less so.

Too bad it's not true.

LWN is a relatively text-heavy site, but an LWN editor's job still requires spending a fair amount of time working with image files. This article, for example, involved grabbing several screenshots, cropping them, generating smaller versions to run inline with the article, etc. There is a simple, unpleasant fact that many Linux users sweep under the rug: the best tool for this sort of light image editing work is xv. A user with a minimal familiarity with xv can plow through a directory full of images, choose one, crop, resize, and save it (possibly in a different format) in less than a minute.

Unfortunately, xv is not free software. It is a "source available" product, and may be freely used "for your own amusement." Any sort of commercial use, however, requires the purchase of a $25 license. Web servers are standing by to take your credit card number. Since xv is not free, it is packaged by few distributors. It remains highly used, however, and packages for most distributions are a quick Google search away.

One would hope that the commercial nature of xv would, at least, encourage its further development. That turns out not to be true either, however; the last entry in the changelog was made at the end of 1994. The current release has been 3.10a since the beginning of 1995. The restrictive license of xv has clearly killed any chance of significant outside contributions, which is unfortunate; xv could use a makeover. In the late 1980's rolling your own widgets for a graphical application was almost mandatory, but there is really no excuse for that now.

Your editor has long wondered why, over all these years and with all the work that has gone into desktop development, nobody has ever come up with a tool for image viewing and simple editing which is anywhere near as quick and easy to use as xv. A proper editor, even a grumpy one, should make an effort to be on top of the state of the art, however, before making such a claim in public. So, what follows is a quick survey of the current image viewer offerings, with a focus on quick editing work.

In particular, here's what your editor wants:

The ability to quickly step through a set of images, preferably with an easy keystroke (such as the space bar).
Display of images in their natural resolution whenever possible.
Fast operations for cropping and resizing images, and for saving the result.
The ability to take a screenshot of another application is a nice bonus.
Also nice, but less important, is the sort of quick color table tweaking that xv supports. One occasionally has to adjust the colors and contrast of a digital photograph, and it can be useful to have quick operations for that sort of task. One reaches a point where it is better to simply fire up the Gimp, however.

What your editor is not looking for is a full digital camera suite, with camera drivers, photo albums, etc. Your editor is also not looking to replace the Gimp, which is an indispensable tool in its own right, but is rather heavy for quick tasks. Finally, your editor will respond grumpily to mail suggesting packages like netpbm or ImageMagick. Those tools are invaluable for scripted applications, and no doubt some clever netpbm hacker could devise a six-stage pipeline involving two separate invocations of the ppmfrobnicate filter to perform all of the tasks above. That is not interesting, however; image viewing and editing is are jobs best done in a graphical mode.

That said, here is a quick overview of several image viewer/editor applications.

Electric Eyes

A number of distributors throw in the "Electric Eyes" application with their GNOME packages. This tool, usually called ee or eeyes, has come a long way over the years; it has most of the capabilities your editor has been looking for. Finding them can be a bit of a challenge, though. The middle mouse button is used for selecting an area to crop, but it simultaneously pops up an "edit controls" window (pictured on the left). That window allows for simple color table tweaking; it also offers a set of inscrutable icons for resizing and rotating the image. A resized image will be saved in its original size, however, unless you click the "apply" icon first; this operation has no visible effect, however. xv, in contrast, has an "original size" checkbox on the save dialog which makes things explicit. The crop operation is not to be found in the controls window; you must select it from a menu attached to the right mouse button.

Unlike most of the applications your editor tried out, Electric Eyes offers a "grab" function for creating screenshots. The process is a little cumbersome, and it employs a truly disturbing strobe effect which is meant [ee resizing demo] to show you which window you had selected. But it works; it was used to generate the ee screenshot.

Electric Eyes appears to have almost nothing in the way of keyboard shortcuts, which slows things down significantly. This editor also has a significant flaw in that the image quality suffers when an image is resized; compare the image to the right (generated with ee) with that just above (generated with xv). The final conclusion is ee, while having a lot of the right features, is not yet ready to replace xv.

gthumb

In many ways, gthumb is the most capable of the tools tried by your editor. It can perform most of the tasks needed, though it lacks a screenshot grab function. The tools can be awkward to use, however. gthumb provides a cropping dialog (pictured on the left) which works by positioning a rectangle over a small version of the image. It has a number of nice options for controlling the aspect ratio of the resulting image. If, however, you are trying to position the crop area with any precision, working on a thumbnail is not the way to go. Selecting a crop area should be done on a full-size rendering of the image.

Speaking of full size, gthumb shares an annoying feature with a number of other image editors: it throws up a window with an arbitrary size that, doubtless, appealed to some GNOME developer; the image being viewed is then resized to fit the window. Your editor, when he wants to look at an image, wants to see the image in its natural resolution. There is a configuration option which can be used to tell gthumb not to resize the image, but it still doesn't size the initial window appropriately. It does, however, remember the way a window was resized the second time an image is viewed.

Resizing of images is done by way of a dialog where the desired size must be specified explicitly. It works, but a quick, immediately visible resize applied directly to the image is faster and better. The quality of images resized by gthumb is good.

There is a set of color tweaking operations which make it relatively easy to fix up digital photos. gthumb also has a number of features you editor wasn't looking for, including "catalogs" (photo albums, essentially) and the ability to attach comments to images. The comments, however, are hidden away in a secret gphoto directory and do not survive if the image is copied or renamed from the command line. gthumb can create index images and web albums as well.

KView and gwenview

KView is a KDE-based image viewer application. Like many KDE applications, KView looks pretty. This image viewer, however, is not up to the task.

KView resizes images on startup (though this behavior is configurable). The application offers a rather clunky zoom interface (you have to pick from a list of percentages) but it has no option to resize an image. It can crop images however (from a selection on the full-size image) and the basic rotate and flip operations are provided. There is also a small list of effects. KView can interface with SANE for easy processing of scanned images.

Another KDE-based viewer is gwenview. As an image viewer, it is nice; it provides a configurable thumbnail window, and keys like the space bar do the right thing (i.e. what an xv user would expect). The only editing operations provided by gwenview, however, are image flipping and rotation. The operations are quick - a simple control-L will rotate the image to the left - but by themselves they are inadequate.

Others

By this stage in the process, your editor was starting to run low on energy. There are, however, several other offerings out there which, perhaps, warrant a mention.

Digikam is a KDE application meant for working with digital cameras. It divides the world into "albums," and reacts badly if you try to start it with a command like "digikam my_image.png". There is a basic set of editing operations, including full-image cropping and gamma and brightness adjustments, but there is no way to resize an image.

Showimg is a KDE viewer which resembles gwenview in many ways. It adds a set of relatively useless image transformation options ("swirl," "implode"), but is unable to crop or resize images. It does have a cute pink cow splash screen, however.

GImageView is a GNOMEish viewer oriented towards working with lots of images. It has a special set of movie options on top of the usual image viewing features. GImageView has an unbelievable number of configuration options. The only editing operation, however, is image rotation - and you can't save the result. For whatever reason, the keyboard shortcut to exit the application is Control-C.

ida is a simple viewer which has obviously been inspired by xv; the right mouse button brings up a control panel, and many of the keyboard shortcuts work the same way. Selecting an area and hitting "c" will crop to that area, for example. Resizing is supported (and the image quality is good), but it requires typing the desired size into a dialog. A small set of image tweaking operations is provided as well. This application has potential, but it needs a faster interface. The Motif-based user interface could also stand an upgrade.

Eye of GNOME is a simple, GNOME-based viewer. The only supported editing operation is rotation; this application has a "save" operation which overwrites the file without question, but no "save as". It is a reasonable image viewer, but it is not useful for editing.

Conclusion

Your editor stands by his original claim: xv, even after nine years of absolutely no development, is still superior to any of the free alternatives. No other tool provides the same ease of use, speed, features, and quality of results. To a grumpy editor, it almost seems as if the developers of free image viewing and editing applications have concerned themselves mostly with quantity. The users of these applications, however, might well be happy to have fewer applications to choose from if a few of them were the same sort of focused, powerful application as xv.

That said, your editor's clear choice for a free image viewer/editor has to be gthumb. The essential set of features is there; all that's left is tuning the interface to make those features quick and easy to use. This application shows potential; your editor will be watching it.

Comments (101 posted)

The 2004 Debian Project Leader election

March 24, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

It's election time again. The Debian Project is holding its annual election for Debian Project Leader (DPL). This year, three candidates are running for the office: current DPL Martin Michlmayr, Gergely Nagy, and Branden Robinson. Debian Developers also have the option of voting for "none of the above" if they prefer.

We contacted each of the DPL candidates with several questions about themselves and their intentions in running for office. We also combed through the discussion on the debian-vote list, where the candidates have been participating in discussions about the Debian project, and why they are qualified to be DPL -- or why they are not. We have attempted to distill all of this information into a brief summary of the candidates' platforms and ideas, but we recommend that LWN readers interested in the DPL election also take the time to read each candidate's platform (they are all available on this page) as well as the relevant DPL threads on debian-vote.

It's typical for candidates for any office to assure their voters that they take that office seriously. Not so with Nagy, who it seems is running on a whim. Nagy is a 22-year-old student living in Hungary, who is running "for fun and profit, of course!"

Past DPL elections were too serious for my taste, too much political stuff, and not much fun. For me, Debian is a hobby, and a hobby should make me laugh at times. That is what I intend to do by running and giving nonsensical answers to otherwise good questions.

He asks Debian Developers not to "even think about voting for me", and says he would resign immediately in the event he does win. Michlmayr and Robinson are a bit more serious about the election.

In addition to serving as DPL, Michlmayr notes that he is also working on a Ph.D. at the University of Cambridge. He says that he is researching quality management in free software. Michlmayr already holds Master degrees in Philosophy and Psychology from the University of Innsbruck, and a Masters in Software Engineering from the University of Melbourne. Michlmayr told LWN that he is running for a second term as DPL to continue his work:

Due to the size of Debian, the project requires a lot of coordination and leadership in order to keep the project running smoothly. While we have a high number of excellent developers and package maintainers, few people are interested in or have the skills to coordinate the project. I have been involved in coordination activities for many years, and think that this is the area where I can contribute most. I have acted as Debian Project Leader for almost a year now, and feel that I have done a good job. I would like to continue my work, and thereby make sure that the project runs smoothly and that other people in the project can carry out their work. I'd also like to continue representing the project to the outside, by attending conferences and talking to companies.

The kind of tasks I carry out as DPL are summarized in my "6-month retrospective."

Robinson lives in Indianapolis, Indiana and has worked for Progeny for the past three and a half years. He has been a Debian Developer since 1998, and served as Treasurer of Software in the Public Interest (SPI) from August 2001 to February 2004. Robinson points out in his platform several reasons why he is running for DPL. Robinson writes that Debian needs improved, more open, and more visible processes. Robinson also says in his platform that the Debian Project should "take our Constitution more seriously", and that the Debian project needs "a leader who will champion our cause:"

Debian is making inroads, seemingly everywhere; I want to accelerate that process and evangelize Debian everywhere I can. I don't see the phenomenon of subprojects or compatible forks as a threat to us at all; instead, it is a beacon of our success. It's my opinion that it is within our power to make Debian a de facto industry standard; the company I work for achieved certified LSB compliance for a snapshot of Debian "sarge" in January. I was enthusiastic about Debian from the day I became a maintainer, and I'm still excited today. Furthermore, I can effectively communicate that enthusiasm and excitement to an audience.

Since the DPL serves a one-year term, we asked each of the candidates to identify the biggest challenge facing Debian over the next year. We also asked candidates to rate the "health" of Debian, and whether the "market share" of Debian as a Linux distribution was a concern. Michlmayr responded:

I think market share is important, and the recent Netcraft survey showed us that Debian is doing very well. One of the big challenges will be to adopt a faster release cycle, and to support current hardware better. We also increasingly have to work with companies, to get better support for Debian (commercial support, hardware support, having Debian pre-installed).

In his platform, Michlmayr also lists several goals he has for the next year. In addition to a faster release cycle, he says that Debian needs a clear release plan for the coming release and for the release cycle for the next few years. He also cites a desire to work with external projects to help reduce duplication of effort between Debian-based distributions.

Robinson told LWN that he sees scalability as the top problem for Debian in the next year:

The biggest challenge facing us is our answer to the question "how can we scale?" We're huge -- over nine hundred developers, at least half of whom are active enough to have participated in the "non-free" General Resolution process, which means we probably have on the order of four to five hundred reasonably active developers. Even that figure dwarfs the engineering staff of all but the largest software companies.

We're also huge in terms of distribution. The Debian "sarge" release is anticipated to consume 13 CD-ROMs' worth of space for the x86/IA-32 binary packages alone... We're also big in terms of infrastructure. We have, at present, 35 project machines in our LDAP database. This doesn't list many quasi-official machines, such as many in the build-daemon network which keep our packages built for all eleven of our architectures. Just about any serious Linux user can imagine how much work it would be to keep that much hardware up and running; an experienced sysadmin knows of whole new dimensions to the problem. Add to that the fact that in many cases, our top-tier administrators don't have easy physical access to these machines, and the scope of difficulty is magnified again.

As for market share, Robinson said that it is something that the DPL "should be cognizant of, though his or her ability to directly affect it is almost nonexistant". Robinson also said that he is "not too worried", about the relative market share of Debian and that he "cannot help [but] be aware of the rising tide that is Debian".

Debian Developers recently rejected a proposal to remove non-free. However, each of the candidates for DPL says that they support removal of non-free from Debian. Robinson said that non-free software does not directly serve the Debian mission, and pointed out that many voters may have misconceptions about the nature of non-free:

Time and again during the long discussions leading up to the vote, the preservation of the non-free section was defended on the grounds that it would take packages away from users -- often using as examples packages which weren't actually *in* the non-free section, hadn't been for years, and for which there was no reasonable expectation of return.

Advocates of dropping non-free, like myself, need to do a better job of dispelling this sort of fear and ignorance, so that people who favor its retention at least can do so on informed and rational grounds. If we do, at some point in the future when the issue is revisited, if the proposal fails again, it will at least do so based more on its actual shortcomings, rather than imaginary horrors.

Michlmayr also wants to get rid of non-free, and points out that as long as Debian maintains non-free that it is less likely that free software alternatives will be created to replace the non-free packages. He said that he was not surprised by the vote, because "the non-free removal was not approached properly".

The non-free opponents simply wanted to remove the non-free packages, but did not offer a transition plan. While there has been talk of moving the non-free packages to an APT repository on non-free.org, nobody has done so yet. In the interest of our users, I think we should first move non-free packages to an outside project, help them get started, and mirror their packages on our mirrors for a year or two to let users switch to the new APT repository...At that point, we can stop distributing those packages ourselves.

Another issue that comes up from time to time is Debian's support for multiple architectures. We asked the candidates whether support for multiple hardware platforms was slowing the project, and when Debian should consider dropping a hardware platform. Nagy responded that if any architecture were dropped, "it should be x86, period...Debian being the Universal OS, should support all possible architectures, and as long as there are people who do the porting work, the support for the platform must be kept".

According to Robinson, the answer should be to improve the build infrastructure:

If an arch proves to be unsustainable, I think we should probably officially discontinue it rather than move it into some sort of "slow lane". If there aren't enough people dedicated enough to keep the port alive in Debian, I suspect there won't be enough people to keep it alive *outside* Debian, either.

In his response to LWN, Robinson also said that Debian should stop supporting a platform "when our developers are no longer able to maintain it to our standards". According to Robinson:

That some architectures take days to compile packages that on modern CPUs take only hours is, interestingly enough, less of a real problem than packages that slip through the cracks and don't get built at all.

Michlmayr also said that support for multiple hardware platforms was not the cause for slow releases:

Supporting the number of platforms we do is certainly a challenge, but it is actually not the main reason we're sometimes slow. I think the community benefits from our wide support of platforms, since we report lots of toolchain bugs (GCC, binutils) on many architectures; we also support some architectures nobody else supports, and it would be a pity if nobody supported the[m] anymore. One reason why Debian has slow releases is the number of packages, and that some of these are not well maintained. This is an issue we have to approach, possibly by moving to maintainer teams rather than relying on a single maintainer for a package.

Finally, we asked the candidates about their thoughts on projects that make use of Debian, such as Progeny's "Componentized Linux," and Bruce Perens' UserLinux, and whether companies like Lindows.com and Xandros were giving enough back to the Debian Project.

Michlmayr said that he has contacted some of the companies that make use of Debian, and that he thinks that "closer cooperation is very important". He notes in his platform that there is limited cooperation between the Debian-based distributions, and that there is development that is not being integrated back into Debian.

As the Debian Project Leader, I would see it as my duty not only to work with these external projects, but to try to internalize them as much as possible. This is partly happening already, but I'd like to work with other projects more closely to drive this process along. As an example, Skolelinux (who have always contributed their work to Debian) first adopted our debian-edu project and are now moving towards using the debian-edu name as their brand. Furthermore, after discussions with developers of DeMuDi (a multimedia distribution based on Debian), they agreed to join our debian-multimedia project and to merge their work into Debian.

Debian will benefit to a great degree if more Debian based projects get involved and make contributions. I am very excited about this because many of those projects are sponsored by local governments. Just imagine the great advances we can make if there are a few paid people in countries like Brazil, Greece, Norway and Spain (which are all working on Debian based distributions). While I cannot control what those projects do, I intend to work together with them as closely as possible. Everyone will profit by more cooperation, and I am interested in helping with the coordination to make this possible.

Robinson responded that one problem presented by the many Debian-based projects, and the "vast amounts of Free and Open Source software that we see today", is that it's hard for people to determine whether the problem they're trying to solve has been solved already.

This isn't just a matter of finding out whether there's a Freshmeat, or SourceForge, or GNU Savannah project in the problem space. That's relatively easy. What's more difficult is finding out whether existing solutions are mature, robust, and a good fit for the remainder of your software (or organizational) infrastructure....

That, I think, is the challenge that Bruce Perens's UserLinux and Progeny's Componentized Linux initiatives are rising to meet. I don't believe it's any accident that two former Debian Project Leaders are among the first to appreciate this need. They witnessed first-hand the incredible breadth of the software prepared by the Debian Project, a breadth that has increased supra-linearly over time.

As to the question of whether companies give enough back to Debian, Robinson says, "yes and no".

I think these companies -- Progeny included -- do a good job of promoting the Debian name, and authoring freely-licensed enhancements to it. The challenge appears to be in coherent integration back into the Debian distribution itself...

I think this takes some initiative from both sides. In my Platform, I proposed officially delegating ambassadors or liaisons from the Debian Project to other organizations, and this can certainly include companies like Lindows and Xandros. At the same time, these companies need to be willing to pay someone to serve a complementary function on their end -- someone who will work with Debian and not let requests for information fall on the floor.

The current system, he notes, may be confusing for developers inside a company like Lindows or Xandros who wish to contribute but are unsure of the proper way to go about it. A Debian liaison to a company would serve as an interface between the Debian project and companies utilizing Debian and looking to contribute back to the project.

The DPL election will continue for a few more weeks. Debian Developers have until April 10 to cast their votes for the Debian Project Leader (DPL), give or take fifteen hours due to a snafu in sending out the call for votes. Good luck to all the candidates, and may the best developer win.

Date	Event	Location
March 25 - 26, 2004	PyCon DC 2004	Washington, D.C.
March 25 - 26, 2004	Novell BrainShare 2004	Salt Lake City, Utah
March 25 - 26, 2004	Open Source Forum 2004	(The Sydney Marriott Hotel)Sydney, Australia
March 27 - 28, 2004	Nordic Perl Workshop 2004	(Symbion Science Park)Copenhagen, Denmark
March 27 - 28, 2004	YAPC::Taipei::2004	Taipei, Taiwan
March 29 - April 1, 2004	Embedded Systems Conference	(Moscone Center)San Francisco, CA
March 31 - April 2, 2004	USENIX Conference on File and Storage Technologies(FAST '04)	(Grand Hyatt Hotel)San Francisco, CA
April 5 - 7, 2004	Samba eXPerience 2004	(Hotel Freizeit In)Göttingen, Germany
April 5 - 8, 2004	ClusterWorld Conference & Expo	(San Jose Convention Center)San Jose, California
April 13 - 15, 2004	Real World Linux 2004 Conference & Expo	(Metro Toronto Convention Centre)Toronto, Ontario, Canada
April 14 - 16, 2004	MySQL Users Conference and Expo 2004	(Peabody Hotel Orlando)Orlando, FL
April 14 - 17, 2004	ACCU Spring Conference 2004	(Randolph Hotel)Oxford, England
April 16 - 18, 2004	Penguicon 2.0	(Detroit Sheraton Novi Hotel)Novi, MI
April 20 - 21, 2004	LinuxUser & Developer Expo	(Olympia)London, England
April 22 - 23, 2004	2004 Desktop Linux Summit	(Del Mar Fairgrounds)San Diego, California
April 26 - 27, 2004	Digital Media Project Traditional Rights and Usages Workshop	Los Angeles, CA
April 29 - May 2, 2004	2nd Linux Audio Developers Conference	(Institute for Music and Acoustics)Karlsruhe, Germany
May 3 - 5, 2004	International PHP Conference 2004 Spring Edition	Amsterdam, Netherlands
May 6 - 8, 2004	TheServerSide Java Symposium	(The Venetian)Las Vegas, NV
May 16 - 18, 2004	European Firebird Conference 2004	Fulda, Germany
May 17 - 20, 2004	Fifth LCI International Conference on Linux Clusters	(University of Texas)Austin, TX
May 17 - 19, 2004	Enterprise Software Summit	(The Palace Hotel)San Francisco, CA
May 17 - 20, 2004	Black Hat Briefings Europe 2004	(Grand Hotel Krasnapolsky)Amsterdam, the Netherlands
May 17 - 21, 2004	Apache Boot Camp	Atlanta, GA
May 20 - 22, 2004	Austrian Perl Workshop	Vienna, Austria

From:		"Andrew Stuart" <astuart-AT-mira.net>
To:		<lwn-AT-lwn.net>
Subject:		Letter to the Editor
Date:		Sun, 21 Mar 2004 02:21:18 +1100

From:		Jonathan Day <imipak-AT-yahoo.com>
To:		letters-AT-lwn.net
Subject:		Release Early, Release Often
Date:		Fri, 19 Mar 2004 06:01:00 -0800 (PST)

From:		"Michael J. Hammel" <mjhammel-AT-graphics-muse.org>
To:		lwn-AT-lwn.net
Subject:		XNotesplus - calendar support (and comments on Grumpy Editor column)
Date:		19 Mar 2004 16:57:54 -0600

From:		Leon Brooks <leon-olc-AT-cyberknights.com.au>
To:		Anthony_Doesburg <Anthony_Doesburg-AT-idg.co.nz>, Peter Moore <petemoor-AT-microsoft.com>
Subject:		It's a step in the right direction, but only a step
Date:		Tue, 23 Mar 2004 09:36:10 +0800
Cc:		LWN Letters <letters-AT-lwn.net>, linux-aus-AT-lists.linux.org.au

LWN.net Weekly Edition for March 25, 2004

Electric Eyes

gthumb

KView and gwenview

Others

Conclusion

Security

Brief items

New vulnerabilities

ecartis: several vulnerabilities

httpd - vulnerabilities fixed in Apache HTTP Server v2.0.49

Resources

Kernel development

Brief items

Kernel development news

Patches and updates

Kernel trees

Architecture-specific

Core kernel code

Device drivers

Documentation

Filesystems and block I/O

Memory management

Security-related

Distributions

News and Editorials

Distribution News

New Distributions

Minor distribution updates

Distribution reviews

Development

System Applications

Audio Projects

CORBA

Database Software

Networking Tools

Peer to Peer

Printing

Web Site Development

Desktop Applications

Data Visualization

Desktop Environments

Electronics

Financial Applications

Games

GUI Packages

Imaging Applications

Interoperability

Medical Applications

Office Applications

Office Suites

Science

Web Browsers

Word Processors

Miscellaneous

Languages and Tools

C++

Caml

Java

Lisp

Perl

PHP