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.
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 ability to take a screenshot of another application is a nice
- 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
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
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.
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
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.
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,
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
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.
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 (100 posted)
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
, and Branden
. 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
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
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 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
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
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
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.
Comments (none posted)
We have been getting a steady stream of mail from readers who are having a
hard time logging in with Internet Explorer. If you are using IE, and you
are having trouble logging in or getting your password sent to you, please
have a look at this update
; chances are it will solve your problem.
Comments (20 posted)
Page editor: Jonathan Corbet
Next page: Security>>