Shallow Thoughts
Akkana's Musings on Open Source, Science, and Nature.
Sat, 16 Aug 2008
Last night Joao and I were on IRC helping someone who was learning
to write gimp plug-ins. We got to talking about pixel operations and
how to do them in Python. I offered my arclayer.py as an example of
using pixel regions in gimp, but added that C is a lot faster for
pixel operations. I wondered if reading directly from the tiles
(then writing to a pixel region) might be faster.
But Joao knew a still faster way. As I understand it, one major reason
Python is slow at pixel region operations compared to a C plug-in is
that Python only writes to the region one pixel at a time, while C can
write batches of pixels by row, column, etc. But it turns out you
can grab a whole pixel region into a Python array, manipulate it as
an array then write the whole array back to the region. He thought
this would probably be quite a bit faster than writing to the pixel
region for every pixel.
He showed me how to change the arclayer.py code to use arrays,
and I tried it on a few test layers. Was it faster?
I made a test I knew would take a long time in arclayer,
a line of text about 1500 pixels wide. Tested it in the old arclayer;
it took just over a minute to calculate the arc. Then I tried Joao's
array version: timing with my wristwatch stopwatch, I call it about
1.7 seconds. Wow! That might be faster than the C version.
The updated, fast version (0.3) of arclayer.py is on my
arclayer page.
If you just want the trick to using arrays, here it is:
from array import array
[ ... setting up ... ]
# initialize the regions and get their contents into arrays:
srcRgn = layer.get_pixel_rgn(0, 0, srcWidth, srcHeight,
False, False)
src_pixels = array("B", srcRgn[0:srcWidth, 0:srcHeight])
dstRgn = destDrawable.get_pixel_rgn(0, 0, newWidth, newHeight,
True, True)
p_size = len(srcRgn[0,0])
dest_pixels = array("B", "\x00" * (newWidth * newHeight * p_size))
[ ... then inside the loop over x and y ... ]
src_pos = (x + srcWidth * y) * p_size
dest_pos = (newx + newWidth * newy) * p_size
newval = src_pixels[src_pos: src_pos + p_size]
dest_pixels[dest_pos : dest_pos + p_size] = newval
[ ... when the loop is all finished ... ]
# Copy the whole array back to the pixel region:
dstRgn[0:newWidth, 0:newHeight] = dest_pixels.tostring()
Good stuff!
Tags: gimp, python, programming, performance
[
21:02 Aug 16, 2008
More gimp |
permalink to this entry
]
Sat, 12 Apr 2008
I've been helping out with an extracurricular GIMP class that a
local Linux and free software advocate, Christian Einfeldt,
has organized at a middle school in San Francisco.
The class meets on a Saturday once or twice a month, so there's plenty
of time to forget things between sessions, and most of the kids don't
have a lot of prior computer experience (I'm told many of them are
behavior problems or otherwise "at risk", but I sure wouldn't have
guessed that from their exemplary behavior in class.)
Despite the obstacles, the kids have
learned some impressive image editing skills in a very short time!
Lots of them have figured out how to set their Edubuntu desktop background;
I've seen abstract patterns, photographs decorated in various ways
(today one girl was painting a mouth, hair and jewelry on a photograph
of a chimpanzee's face, and it came out looking very funny), photos
of the students themselves pasted into exotic locales, and so on.
It's also an interesting exercise for me in seeing what
beginning users find difficult to understand and what aspects
of GIMP's user interface are difficult to explain.
An additional challenge is that this classroom
has no projector or centrally visible screen. So you can't just
demonstrate how something works; everything must be explained slowly
in words while the students follow along with each step, and then
we have to go through the room helping students as they try to
remember the steps.
One of the first tasks they take on is combining images: start with
a photo of themselves, or of an animal or car, select it and paste it
into another image. What's the easiest way of explaining selection of
arbitrary shapes?
Which method can be explained in less than a minute, and yet they'll
remember how to do it after you leave and move on to the next student?
There are three obvious candidates for a general-purpose selection
tool: the intelligent scissors, the paths tool, and the quickmask.
We had a miscommunication in one of the early classes and didn't
discuss which technique to teach, so I taught some students the
paths tool while Christian was teaching others the iscissors.
I found that both methods had some serious problems.
With Bezier paths, it's easy to click points around your object.
Students get a little flustered the first few times they accidentally
drag rather than click and drag handles appear, but they can get over
that. The part that's difficult comes at the end, where they have to
click Path to Selection, then Feather as a separate step (they don't
need to feather the first time, but eventually they'll need it).
And then there's the problem that the path as well as the selection
remains visible, a distraction that they don't understand.
When I saw that Christian had been teaching some students the
iscissors while I was teaching others paths, I thought, gee, good
idea. Iscissors should be more straightforward, no? Well, no, as it
turns out. New students have great difficulty making an iscissors
selection. They're fine as long as they're clicking their points; the
problem comes when they get to the last point, when in order to make a
selection you must click carefully on your first point, then click
again inside the figure. A lot of students don't understand this no
matter how many times you explain: they don't remember which was their
first point (it doesn't look any different from the others), they
can't see it anyway (it usually doesn't contrast much with the image),
and they can't tell whether they clicked it successfully.
At that point they try to click inside the image and get a spurious
extra point -- and then they
panic and start clicking all over the place, ending up with a mess
that is (as far as I've been able to tell) unrecoverable. The only
fix is to toss out that figure and start over, but even that isn't
easy to do (click on another tool then back on the iscissors tool
button). Basically, the iscissors tool is far too confusing and most
students need to be personally walked through it at least three times
(some of them a lot more than that) before they get it.
Anyone who's read my writing on GIMP probably knows that I'm a
quickmask zealot. I'm a born again quickmask prophet: I used GIMP for
years without really understanding the quickmask, and when I finally
grokked it, it made a huge difference in ease of selection.
I sometimes joke that "the quickmask changed my life", and that's
hyperbole, or course; but it sure did change my GIMP editing.
People seem to fear the quickmask so I usually don't present it
first, but maybe I should. These students are very eager and competent
at painting, and I think they'd take to the quickmask very easily
with far fewer stumbles than the other two methods have given them.
There's one other variant of shaped selection that I didn't list:
the lasso tool in add and subtract mode. The lasso tool is
terrifically hard to use to try to select a whole figure from
an image. You'd have to have a preternaturally steady hand, plus
you can't zoom in and scroll around since the whole figure has to
be completed in one movement. But what you can do is make a rough
selection with the lasso, understanding that you'll have some errors;
then alternate between Add mode and Subtract mode as you use the lasso
on smaller areas to get the selection just right. It's nearly as easy
as the quickmask, and doesn't require a big conceptual shift. The only
reason I'm leery is that I suspect the three modes would confuse a lot
of students -- especially since the mode buttons have no labels,
merely tooltips.
While I'm on the topic, there's another issue that gives the students
trouble besides selection: the floating selection that results from a
paste. There's really no way to explain to a schoolkid why it's there
(heck, maybe some day someone will explain that to me).
And it's useless to try to get them to keep their Layers dialogs
visible. (They don't even keep the toolbox visible most of the time;
it's always covered by image windows. Most of these Edubuntu machines
are working at 800x600 resolution, and there just isn't room on the
screen for the normal GIMP window collection.)
So I try to drill them that "Every time you paste, you have to find
the Layers window and click that button on the bottom left."
Understandably, they often forget that step, then get into trouble because
they can't see all their pasted layer, or some functions are greyed out.
Aside from selection and paste, the students seem to cope with GIMP
remarkably well. Some of them have been exploring the menus for fun
plug-ins, others are trying different patterns to make interesting
backgrounds, and one even discovered how to make interesting effects
with some of the specialized gradients. At the beginning I wondered
if teaching GIMP might not be too ambitious, and maybe something
simple like Tux Paint might be better. But GIMP is working out just
fine except for those few stumbling blocks.
The kids have a refreshing willingness to explore and try things, and
the result is a whole lot of really fun images.
Tags: gimp, education, user interface
[
22:44 Apr 12, 2008
More gimp |
permalink to this entry
]
Tue, 26 Feb 2008
I've wished forever that GIMP could open files and URLs as easily as
Mozilla (and Netscape before it) does by selecting the filename in
another app then middleclicking to "paste" in the toolbox.
(Note: in Mozilla this is controlled by the
middlemouse.contentLoadURL preference, and Ubuntu users have
to enable it explicitly.)
Well, it turns out GIMP has that feature too, and has had it for a
long time. The reason it had never worked for me is that it only
works if you click on one (any) of the tool buttons. I was clicking
in empty areas of the toolbox window, because it feels weird to
click over a button when I don't mean to use that tool.
Now that I know to middleclick on a tool button, middlemouse open
works great for Unix paths, file: URLs and even remote URLs
(assuming you have Open URL working, of course, which on some
systems may require installing gimp-libcurl or gimp-gnomevfs).
Nice! That'll save me some gimp-remote calls.
Tags: gimp
[
15:21 Feb 26, 2008
More gimp |
permalink to this entry
]
Sun, 17 Feb 2008
There's been some discussion on the gimp-developer list about that
unwieldy layer mode option menu you see in both the Layers dialog and
in drawing tool options.
Bill
introduced the topic
by suggesting a redesign of the menu to use
two side-by-side columns instead of one. That makes the menu more
compact and vastly shortens the average mouse movement needed to
change modes.
But Sven didn't like the side by side option, pointing out that it
implies some equivalence to modes that end up listed next to each other.
More discussion ensued, with Bill posting a
screenshot of the unwieldy
menu to illustrate how bad it is
(including the bizarre gtk "the top half of the menu is blank"
misfeature that always looks like a bug but is apparently intentional).
That Mode menu has always bothered me.
Typically when I'm using layer modes, I try lots of them
one by one to see which mode works best.
But that's difficult with the current very tall menu, especially
(as Bill pointed out on IRC)
if you need to jump back and forth between two modes that aren't close
to each other in the menu. And gtk option menu's behavior doesn't help,
where clicking on it pops up the menu but not necessarily with the current
item selected -- sometimes the previous item is selected, so you can't
just arrow down once and assume you'll get the next mode.
That night after going to bed I got to thinking about it.
I realized that the Mode menu problem was similar to the problem
selecting a font from the combo box in the Text tool options --
I usually find it much easier to bring up the Fonts dialog and choose
a font from there. What I really wanted for layer modes was a
"Modes dialog".
And suddenly it came to me that I
could solve most of my problem with a simple "Next mode" script.
Once I had that, I could bind it to a key, or "tear off" the menu it
was in so that it would stay visible and I could click it repeatedly.
It took about ten minutes the following morning to write the script
in python.
Cool!
I posted my solution back to the list, and some discussion ensued on
IRC. Bill pointed out that enabling tear-offs for the existing
Mode option menu (which can be done in two lines of C code)
gives essentially the Fonts dialog I wanted.
Several of us thought that was a great idea.
But when Bill posted to the list, Sven nixed the idea, saying
tear-offs were deprecated. (They're not officially deprecated in GTK,
or at least the GTK documentation doesn't say so and I can't find
anything with google; but in any case Sven apparently doesn't like
tear-offs and won't allow adding any new ones in GIMP.)
Fortunately, gimp-python comes to the rescue here too. Writing a
mode-dialog.py
turned out to be a little trickier than "next mode",
only because it took me a while to realize I needed to call
pdb.gimp_displays_flush() to update the display after
changing the mode of the current layer (thanks Alexia and Bill).
So now I have both "next mode" and a separate mode dialog,
making layer mode operations so much easier!
Tags: gimp
[
11:50 Feb 17, 2008
More gimp |
permalink to this entry
]
Sun, 21 Oct 2007
I ran out of business cards (where do they go? I never seem to find
occasion to give any out. They make good bookmarks, though) and
wanted to print some more. I use gLabels for low-res label printing,
but it prints poorly (or used to, anyway) so when I want something
with crisp and sharp images, I use GIMP with my
GIMP Labels
script.
That's all fine, except that the "make label page" part of the script
scales the labels to fit on a typical Avery letter-sized template --
and the Gutenprint drivers for my printer can't actually fill a
letter sized page. (I have the choice of normal printing, in which
it fills about 97% of the page, or Borderless printing, where it
slops way over the edges.)
The solution is to crop a little extra off the outside edge of the
label page. So I added some code to script-fu-rect-label-page to
keep a "Printer fudge factor" and crop the page at the end.
An easy tweak which seems to work fine, and with any luck it'll
cure a lot of the misalignment problems I've seen with labels.
While I was making changes anyway, I added some clearer installation
instructions for the 95% case of someone who just wants the script
with the labels I've included, since I recently heard from someone who
wasn't clear on where to install the script.
Tags: gimp
[
12:03 Oct 21, 2007
More gimp |
permalink to this entry
]
Sat, 09 Dec 2006
Another person popped into #gimp today trying to get a Wacom tablet
working (this happens every few weeks). But this time it was someone
using Ubuntu's new release, "Edgy Eft", and I just happened to have
a shiny new Edgy install on my laptop (as well as a Wacom Graphire 2
gathering dust in the closet because I can never get it working
under Linux), so I dug out the Graphire and did some experimenting.
And got it working! It sees pressure changes and everything.
It actually wasn't that hard, but it did require
some changes. Here's what I had to do:
- Install wacom-tools and xinput
- Edit /etc/X11/xorg.conf and comment out those ForceDevice lines
that say "Tablet PC ONLY".
- Reconcile the difference between udev creating /dev/input/wacom
and xorg.conf using /dev/wacom: you can either change xorg.conf,
change /etc/udev/rules.d/65-wacom.rules, or symlink /dev/input/wacom
to /dev/wacom (that's what I did for testing, but it won't survive a
reboot, so I'll have to pick a device name and make udev and X
consistent).
A useful tool for testing is /usr/X11R6/bin/xinput list
(part of the xinput package).
That's a lot faster than going through GIMP's input device
preference panel every time.
I added some comments to Ubuntu's bug
73160, where people had already described some of the errors but
nobody had posted the steps to work around the problems.
While I was fiddling with GIMP on the laptop, I decided to install
the packages I needed to build the latest CVS GIMP there.
It needed a few small tweaks from the list I used on Dapper.
I've updated the package list on my GIMP Building
page accordingly.
Tags: linux, X11, imaging, gimp, ubuntu
[
15:12 Dec 09, 2006
More linux |
permalink to this entry
]
Thu, 23 Nov 2006
People keep showing up on GIMP's IRC channels and asking about
JPEG 2000 support. There was a
Summer
of Code "Wavelet" project last summer which implemented JPEG 2000 support
(among other things) but no one ever seems to know where to find it.
So I asked Simon, who was the mentor for that project. Turns out
he had tarballs, but didn't think it was appropriate to link them
from his own site, especially as they were somewhat tricky to
compile.
The consensus among the developers was that it would be nice to
have jp2 and the other wavelet plug-ins available on the
GIMP Plug-in Registry.
So I fiddled with them, fixed a couple of Makefile issues,
added READMEs with author credit and building instructions,
and uploaded them to the registry. The plug-ins are:
- jp2
- JPEG 2000 support
- denoise
- A noise removal plug-in
- ihalf
- Inverse halftoning -- remove halftones from printed images.
I haven't actually used these plug-ins (couldn't find a JPEG2k file
to test) -- I just wanted to help
make them available for people who need them.
While I was at it I updated my vastly out-of-date registry
entries for Pandora and added an entry for my label/business card
script.
Tags: gimp
[
12:54 Nov 23, 2006
More gimp |
permalink to this entry
]
Tue, 15 Aug 2006
"Favicons" are those little icons you see to the left of the URLbar
in a browser, and for each site in the bookmarks menu or toolbar.
They're just a file named
favicon.ico in the top level of
a web site, and they're a nice addition to a site.
(More details in the
Wikipedia entry.)
I'd made a few favicons in the distant past by creating a
32x32 image, saving it as ppm, then using ppmtowinicon.
But when I tried it in GIMP recently, I ran into trouble.
GIMP can save ICO files: Save As, click Select
File Type and choose "Microsoft Windows icon (ico)".
That gets you a dialog where you have to choose a color depth and
palette. I tried different settings, but the resulting images
never showed up properly in Firefox.
But then I tried saving as ppm and using ppmtowinicon and
that no longer worked either. Argh! What's up?
The silly answer, it turns out, is that it had nothing to do
with how GIMP was saving the images. The problem was that Firefox
caches favicons, and shift-reload or Clear Cache doesn't help.
When you're testing a new favicon, you have to load the url
for the favicon.ico itself (and reload it if necessary).
Success at last! It even handles transparency, so you can
make shaped favicons that show up nicely against a tab, menu
or toolbar background.
Of course, editing a 32x32 pixel image is a fun exercise in itself.
I recommend using a second view (View->New View).
Expand one view a lot (800x works well) so you can edit individual
pixels, while the other view remains at normal size so you can see
your final icon as others will see it in the browser.
Tags: gimp
[
10:57 Aug 15, 2006
More gimp |
permalink to this entry
]
Tue, 18 Jul 2006
I got slashdotted yesterday -- a positive
Slashdot
book review of Beginning GIMP. Hooray!
The comments were mostly the usual mix of flames from
Photoshop users saying "GIMP sucks because it isn't like Photoshop",
with hardly anything about the book; no surprise there.
I don't know why Photoshop users seem so compelled to attack
the GIMP, but obviously they do since this happens so often.
They don't seem to be willing to accept "Some people like one
style of user interface, other people like another style, and
a highly complex application like GIMP or Photoshop is going
to take some time to learn no matter how it's designed."
Slashdot linked to Barnes
& Noble rather than Amazon, which is understandable
since BN has a killer 40% off sale in progress on Apress books
(they have
at $26.99 for BN members,
$29.99 otherwise).
Apress also pointed me toward a couple other reviews that I hadn't
seen yet, so I created a review
page to link to them.
Tags: gimp
[
17:37 Jul 18, 2006
More gimp |
permalink to this entry
]
Sat, 27 May 2006
Dave thought I wasted too much presentation time
reversing the layers in my panorama example prior to running
Pandora.
I'm sure he's right.
The problem is that GIMP's "Open as Layers", if you select multiple
layers, opens them in the opposite direction from the way you'd
generally expect to use them in a panorama, with the lexigraphically
first layer on the top of the stack rather than the bottom.
The very next day, someone showed up on IRC asking how to reverse layers,
because "Open as Layers" opened them in the wrong order to use for an
animation.
At Mitch's suggestion, I wrote a reverse-layers script-fu (which Mitch
improved by pointing out that it didn't handle the possible error case
of a floating layer. As it happens, re-ordering floating layers works
fine in current CVS, but apparently it's not supposed to. I suspect
being able to move layers without alpha off the bottom position in
the stack may also be a bug, so I added a guard against that).
(Update: No, it turns out it's intentional that non-alpha layers
can be moved anywhere in the stack in 2.3.)
Layer->Stack->Reverse Layer Order is now included in CVS GIMP,
but for users of earlier versions I've made it available:
reverse-layers.scm.
Meanwhile, I made a new version of Pandora which can build a
panorama in either direction. I still find it slightly jarring to
assemble a panorama from right to left after building them from
left to right for so long, but maybe I'll get used to it.
I caught another bug at the same time: I was testing one of the
parameters set in the GIMP dialog (which sets a toggle to either TRUE
or FALSE) like this:
(if use-mask (do-stuff))
That doesn't work in script-fu.
Turns out TRUE is just an integer, while if
apparently only tests for Lisp nil or non-nil. So you have to say
(if (= use-mask TRUE) (do-stuff))
if you want tests to work against booleans coming from GIMP dialogs.
Tags: gimp
[
22:22 May 27, 2006
More gimp |
permalink to this entry
]
Fri, 26 May 2006
It's been a busy couple of weeks. My book (
Beginning GIMP: From Novice to Professional)
finally started arriving on people's doorsteps.
I first found out it was shipping from an email from a reader
in Ohio: "I just received your book, and I have a question ..."
He was the first of the Amazon shipments.
Over the next few days, more Amazon shipments started trickling in --
my mom got hers, a couple of friends got their copies. But it was
nearly a week before either I or the home office of Apress received
our copies, so in the meantime I was pumping everyone I knew for
information -- "How does it look?"
Finally my copies arrived. It's beautiful! I'm so happy with the
printing job Apress arranged. Bright colors on thick glossy paper. The
colors are surprisingly different from what I saw on the PDF that went
to the printer -- the active window borders on all the screenshots
(royal blue on my screen) are almost purple!
Now I can better appreciate why people who print professionally
care so much about details like ICC color profiles. Fortunately, I
knew there might be some color shift, so none of the figures in the
book depend on exact colors (the RGB color circles aren't precisely
Red, Green and Blue, but I'm sure readers will understand them).
So now I'm on the lecture/booksigning circuit. What fun!
I've only given a couple of talks so far; last night was a PenLUG talk that went well, with
lots of audience questions. The audience ranged from beginners to
experienced graphics programmers to someone who's interested in using
GIMP in a scientific context (comparing images; I told him about
the geologist I talked to a few months ago who was doing just that,
using Difference or Subtract layer modes to compare two aerial photos
of the same area) to a professional photographer who uses GIMP in his
work. One of the great side benefits of speaking about GIMP is getting
a chance to hear all the ways people use it for different purposes.
I made some business cards to hand out, but no one takes them.
That's okay: it was a good excuse to fiddle with my
gimplabels
script-fu and learn how to print really nice business cards from GIMP.
Making business cards is easy with gLabels, but since it uses
gnome-print it can only print using the system's default settings,
which makes for really chintzy looking, pixellated cards.
Gimp-print, on the other hand, can print in high resolution to nice
glossy photo-quality card stock.
I'm gradually learning how to give a better GIMP talk,
collecting interesting examples to show and minimizing the
time spent fumbling over menus or waiting for progress bars.
And dealing with the occasional glitch:
last night, SIOX for some reason refused to select my flower image,
after working perfectly the hundred or so previous times
I've used it on that image.
(What timing! Just last week I also received my ATM-B award from
Toastmasters.
Too bad outside GIMP talks don't count toward the next level.)
Fortunately GIMP is very visual, so it's easy and fun to find whizzy
examples and techniques that most people haven't seen before.
People have lots of interest in GIMP and image editing in general, and
they want to hear more about it and have lots of questions. It's a
topic everyone can appreciate. After all, who doesn't like looking at
cool images?
Tags: gimp
[
10:32 May 26, 2006
More gimp |
permalink to this entry
]
Sun, 19 Mar 2006
Periodically I get requests from people without C compilers (which
usually means Windows users) who are interested in using my
GIMP plug-in
Pandora,
which helps with making panoramic images
by loading all the images, positioning them approximately, and
adding layer masks. I always regret that I don't have a Windows
binary to offer people.
I've been thinking for a while that it would be easy to do a Pandora
plug-in in script-fu, so that any GIMP user could run it.
The only reason Pandora was written in C is
that it provides a modified file selection dialog allowing you to
choose the files you want in sequence. But it's not like the UI
for that dialog is any great shakes (it's always been confusing,
even to me, and I wrote it), and of course it uses the old gtk
file selector, which has been orphaned for quite some time.
The way to work around this in script-fu is to let the user open
all the images as layers in a single image using the normal Open
and Open as Layers functions, then transform that image into
a panorama by resizing it bigger and moving the layers to the right
place. Easy! It's been on my list to do for a long time, but I
didn't get motivated to write it until this morning when I
wasn't doing anything else and another Windows user showed up
on #gimp asking about panoramas.
I should have done it earlier. It only took an hour or two,
and works as well as the old C version. It's available on the
Pandora page.
Feedback or bug
reports appreciated!
Tags: gimp
[
18:02 Mar 19, 2006
More gimp |
permalink to this entry
]
Tue, 14 Mar 2006
People are forever turning up on #gimp to ask (quite reasonably)
how to center a layer, since GIMP offers no built-in way to do that.
There are Python and Perl scripts around somewhere (and
it's easy to write, a great project if you're thinking about
learning how to write GIMP scripts in any language).
And the new Align tool can probably center, for those
using GIMP 2.3, but the tool is a bit difficult for most
people to figure out (fear not, the UI is still being developed).
But for those who want a quick solution:
Center a Layer:
Cut, then paste. The pasted layer comes out centered.
(Unfortunately this loses text information, so if it's a text
layer this isn't an ideal solution.)
Paste a layer on top of a copy of itself:
Do a
Layer to Imagesize before copying.
Then copies of the layer will overlap the original.
Tags: gimp
[
18:51 Mar 14, 2006
More gimp |
permalink to this entry
]
Mon, 30 Jan 2006
Although I haven't been writing about it here, for most of
the past year I've been working on a new GIMP book for Apress, called
Beginning
GIMP: From Novice to Professional.
Today the work was over: the last bits shipped to the printer!
The rest is just waiting (... and waiting ... and waiting ...)
Amazon has a page
on it already (complete with typo in the description; sigh)
for folks who like to pre-order their books months early.
Scheduled release date is currently late April.
(I think they have to grow the trees first.)
In case you haven't already heard other authors say it, writing a
book is a lot more work than you think it will be. Even if other
authors have already told you that it's more work than you think it
will be, it's more work than that. If you thought you already knew
the subject you were writing about, think again. You'll find out how
little you really knew. You'll discover all sorts of options you never
noticed in your favorite tools, and new (and often better) ways to
do things than the methods you'd been using for years.
You'll discover bugs in plug-ins no one's used in a while,
and why things you always thought were bugs really aren't.
That's the good sort of "too much work": the kind that keeps
you learning, so that you come away from it with more than you
started with. It's been fun. But I confess that I'll be glad to take
a rest for a while and work on some long neglected coding projects.
I celebrated ship-to-printer with a little GIMP hacking
(adding that feature list to configure that I
wished
for last week, so now GIMP will warn you of any missing features
before you start your 45-minute build);
and with lamb kebab with zereshk polo at Chatanoga.
Tags: gimp
[
21:38 Jan 30, 2006
More gimp |
permalink to this entry
]
Tue, 24 Jan 2006
I've been frustrated for some time at GIMP 2.3's inability to save
EXIF data whenever I save a JPEG image. There were several bugs
report on the problem, and I just assumed that this was something
which had broken somewhere along the line and hadn't been fixed yet.
It turns out it was a stupid build problem on my machine: I didn't have
libexif-dev installed on either of my Ubuntu systems, and GIMP's
configure script wasn't warning me about it in any obvious way.
(Of course, had I taken the time to read through the 3679 lines of
config.log, the information was buried in there around
line 2199.)
So now I have EXIF again, at least on the laptop (hooray!) but I
also learned something more important: after running configure for
the first time on any new system, before running make, do this:
grep -i "will not" config.log
That may not flag everything, but at least it's a start at getting
a list of features that have been disabled because of dependencies
you forgot to install (anything which configure is smart enough to
tell you "will not be built").
Schumaml had the great idea of putting a list of enabled features
in the About box. Maybe I'll look into doing that in a week or two
(when the current crunch is over and I have more time to upgrade my
development machine so that it can use gtk 2.8 and I can actually
build GIMP again).
Update: I added
a printout similar to the one I thought I remembered, so there
should be no further need to grep for "will not".
Tags: gimp
[
14:11 Jan 24, 2006
More gimp |
permalink to this entry
]
Mon, 29 Aug 2005
Sven, one of the GIMP developers, has been interested in setting up
a "paper prototyping" system for reorganizing the GIMP's menus
(see his
blog
post.
Since I've been involved with some of the ongoing menu
reorganization, we've talked about it a bit, and discussed some
tools that are being written to assist with online paper prototyping
(since the "get everybody together in a room with slips of paper"
model doesn't work for worldwide distributed projects).
But for some reason it never occurred to me until a couple days ago
that GIMP itself would make a fine paper prototyping tool.
The move tool lets you move the text layers into any configuration
you like, you can control colors and fonts, and you can save to your
choice of standard formats.
It didn't take long at all to whip up a script-fu to
enable paper prototyping, which I posted
to the gimp-developer list.
Nobody has actually used my script to comment on the menu reorganization
yet ... but what the heck, it was fun to write the script. Maybe
it'll be useful in other projects that need paper prototyping.
Tags: gimp
[
16:43 Aug 29, 2005
More gimp |
permalink to this entry
]
Fri, 29 Jul 2005
I've switched my desktop machine from straight Debian (unstable, or
"sid") to Ubuntu "Hoary Hedgehog". Sid was just getting
too
unstable for me (I'd been spoiled because it really has been pretty
stable, except for printing problems, for the past few years).
Freetype now has rendering problems, so any fixed width
terminal font is nearly unreadable and many PDFs aren't readable
at all. There are issues related to the switch to gcc 4. But the
last straw was when printing to my Epson C86 stopped working.
(I try to make a point of mentioning bug numbers when I whine about
open source issues. The freetype problem with terminal fonts was
already reported as bug 315150, and I opened bug 319068 on the pdf
issue though I suspect it's part of the same problem.
The gcc4 issues are well known and are just transitional issues.
I didn't bother reporting the printer regression; after over a year
of having similar bugs for my old printer ignored, finally giving
up and buying a new printer specifically so that I could continue
to run Debian, it's hard to have much confidence that reporting
printing bugs is worthwhile.)
The switchover to Ubuntu was surprisingly painless.
The install went fairly smoothly, and
in half a day I was up and running with my environment
(currently fvwm) customized the way I wanted it.
The only problems I've had with hoary are poor rendering of
fixed-width fonts (not as poor as sid with the freetype bug,
but a lot worse than debian used to be) and inability to play mp3
(I suspect I'll hit problems with other formats such as wmv as well,
but I haven't tried yet). The font problem is quite annoying and no
change I make to /etc/fonts/local.conf seems to make any difference.
The mp3 problem probably requires downloading and hand-installing
something -- I hear rumours that there's nothing apt-gettable which
will make non-free formats work, though that seems odd for a distro
aimed at desktop users.
Update 7/31: Turns out there are hoary packages for mp3 handling
after all. Search for "mad" rather than "mp3", e.g. xmms-mad adds
mp3 support to xmms.
But first I had to set up a development environment.
Ubuntu's install is very minimal, since it uses only a single
CD. It doesn't even install gcc by default. So I enabled all the
ubuntu sources (restricted, universe, multiverse) and I've been
gradually adding packages to get back everything I had on sid.
GIMP (2.3, from CVS) seemed like a good build test.
Assembling the dependencies was straightforward but time consuming.
Since people new to building GIMP are often confused about what
they'll need, I kept track of the additional packages I needed,
and posted the full list on my
GIMP building page.
Tags: gimp
[
11:24 Jul 29, 2005
More gimp |
permalink to this entry
]
Mon, 20 Jun 2005
I'm working with the GIMP developers to do some minor reorganization
of some of the menus.
In particular, we wanted to get things like script-fu
and python-fu out of the menus so users don't have to know what
language a function is written in to use it.
That part of the patch (for the image window; the Toolbox Xtns menu
reorganization is still pending) got checked in a few days ago.
Sven is now soliciting comments on the next step on his Planet
Gnome blog. The proposal for the next step is in
bug
116145. There haven't been many comments; I encourage anyone
interested in GIMP's menus to read that bug and comment in it.
The Toolbox Xtns menu reorganization is a bit more complicated,
since there are two conflicting proposals, in bug
145507 and bug
158980. I tried to suggest just moving stuff out of the
Script-Fu menu for now, since there's no agreement on further
changes yet, but that went over like a lead balloon.
So it's back to the image window's Filters menu. If there aren't
any comments in a few more days I'll just go ahead with
the proposal in the bug.
Maybe I'll even get to use my shiny new CVS access to check the
changes in myself. Woo!
Tags: gimp
[
10:49 Jun 20, 2005
More gimp |
permalink to this entry
]
Sun, 08 May 2005
Updating the blog again after taking time off for various reasons,
including lack of time, homework, paying work, broken computer
motherboard and other hardware problems, illness, a hand injury,
and so on.
This afternoon, thanks to a very helpful Keir Mierle showing
up on #gimp, I finally got all the pieces sorted and I now have
a working tablet again. Hurrah!
I've put details of the setup that finally worked on my Linux and Wacom
page.
Tags: linux, imaging, gimp
[
18:08 May 08, 2005
More linux |
permalink to this entry
]
Wed, 02 Feb 2005
Someone showed up on #gimp the other day asking about how to make
business cards. He was on Windows, so gLabels wasn't really an
option, and of course my old gimp-print patch to read gLabels label
templates would have been no help to a Windows user.
I got to thinking about how easy it would be to write a little
gimp script analogous to my CD label script, which created a
rectangular template in which to design a label, then created a
bigger image scaled to the size of a page on which the label
could be repeatedly positioned, with specified start and end points.
I couldn't resist trying it. It wasn't quite as easy as I had
initially thought, mainly because I don't know script-fu very well
and debugging script-fu is painful.
But it still only took a few hours on a couple successive
days to hack up something that more or less works:
GimpLabels.
I didn't try to parse the gLabels XML from script-fu; I wrote a
separate python script to translate the label templates into
script-fu.
It's not perfect. On a page of 30 Avery 5160 labels (10 rows),
it gets a little off by the bottom of the page. I don't know yet
if this is a problem in the gLabels template, in my understanding
of the parameters, or in the script-fu. It's fine for shorter
pages.
I integrated my existing CD label routines into the script, but
haven't yet written code to parse the CD label templates and make
a print page from them. I've lost motivation for working on CD
labels anyway, since discovering a few months ago how drastically
they hurt CD longevity.
Anyway, GimpLabels was a fun hack, and an example of how easy it is
to do this sort of thing in gimp.
Tags: gimp
[
11:20 Feb 02, 2005
More gimp |
permalink to this entry
]
Tue, 25 Jan 2005
I've started my
"GIMP for
Beginners" course on the
Linuxchix
Courses mailing list, topic "gimp".
Anyone reading this is welcome to join in!
Here's the first posting, Lesson
0.
Tags: gimp
[
10:10 Jan 25, 2005
More gimp |
permalink to this entry
]
Tue, 28 Sep 2004
I shot way too many panoramas on the Southpark trip (places like
Canyonlands just don't fit in any normal camera lens) and ran up
against some irritations in
Pandora
when stitching them together.
Notably, it no longer remembered the overlap value from the previous
run, and if you select filenames in the filepicker but don't click
"Add" it just exited silently. Version 0.7 fixes those problems
(Yosh figured out that it needed a call to gimp_main_exit in order
to remember the values),
and cleans up some crufty code that was left over from blindly
copying the gimp sample plugin.
Tags: gimp
[
11:28 Sep 28, 2004
More gimp |
permalink to this entry
]
