Shallow Thoughts

Cleaning up the edges of Moonroot's transparent images

I wrote moonroot more to figure out how to do it than to run it myself. But on the new monitor I have so much screen real estate that I've started using it -- but the quality of the images was such an embarrassment that I couldn't stand it. So I took a few minutes and cleaned up the images and made a moonroot 0.6 release.

Turned out there was a trick I'd missed when I originally made the images, years ago. XPM apparently only allows 1-bit transparency. When I was editing the RGB image and removing the outside edge of the circle, some of the pixels ended up semi-transparent, and when I saved the file as .xpm, they ended up looking very different (much darker) from what I had edited.

Here are two ways to solve that in GIMP:

1. Use the "Hard edge" option on the eraser tool (and a hard-edged brush, of course, not a fuzzy one).
2. Convert the image to indexed, in which case GIMP will only allow one bit's worth of transparency. (That doesn't help for full-color images, but for a greyscale image like the moon, there's no loss of color since even RGB images can only have 8 bits per channel.)

Either way, the way to edit a transparent image where you're trying to make the edges look clean is to add a solid-color background layer (I usually use white, but of course it depends on how you're going to use the image) underneath the layer you're trying to edit. (In the layers dialog, click the New button, chose White for the new layer, click the down-arrow button to move it below the original layer, then click on the original layer so your editing will all happen there.)

Once you're editing a circle with sharp edges, you'll probably need to adjust the colors for some of the edge pixels too. Unfortunately the Smudge tool doesn't seem to work on indexed images, so you'll probably spend a lot of time alternating between the Color Picker and the Pencil tool, picking pixel colors then dabbing them onto other pixels. Key bindings are the best way to do that: o activates the Color Picker, N the Pencil, P the Paintbrush. Even if you don't normally use those shortcuts it's worth learning them for the duration of this sort of operation.

Or use the Clone tool, where the only keyboard shortcut you have to remember is Ctrl to pick a new source pixel. (I didn't think of that until I was already finished, but it works fine.)

Tags: programming, astronomy, gimp
[ 14:48 Nov 16, 2008    More gimp | permalink to this entry ]

Great Advertising

Usually I just delete spam after seeing the subject line. But I couldn't resist one that arrived this morning:

Subject: You'll be saying WOW every time with ShamWow

Wondering whether the seller was familiar with the meaning of the word "sham", I just had to take a look.

I couldn't tell anything from the text -- it was all just random verbiage to try to fool Baysian filters. But the mail also attached two images, img001.png and img002.png. The first was a big grey starburst thing; the second, at 348Kb, was the actual ad (click on it to get the full-sized version; the thumbnail here doesn't do it justice).

There are just so many things to love about this ad, starting with the name "ShamWow" itself. I love the mixture of fonts and bright colors, with the slightly lopsided hourglass shape of the ShamWow! logo. I love the "AS SEEN ON TV" bug -- a charming image that hasn't changed a whit since the 60's, maybe even the 50's. I love the unidentifiable grey and yellow flat things with unreadable text on them -- they look like file folders and folded papers, but they're probably two different colors and sizes of ShamWow -- covered with a square announcing "10 Year [unreadable]", which made me wonder if they were selling auto loans or securities. But if you magnify it you find that the third word is probably "Warranty". I love the presumption that you'll think that 20x the weight of a small cloth object is a lot of water (is it? I have no idea, let me grab a paper towel and a gram scale). I love the blurry red and white "CLICK FOR DETAILS" button.

But what I like best about this image is that it's a PNG but it's full of JPG artifacts. Now, I'm not very picky about jpeg artifacts. (You'd think I would be, as a de-facto GIMP expert, but I'm really not.) I shoot DSLR photos in jpeg rather than raw mode because most of the time the difference just isn't enough for me to care about. I use jpeg for most of the icons on my web site if they don't need transparency, and I lower the jpeg quality level to make them load faster. I'm not a PNG snob (actually, I'm more likely to use GIF than PNG for web icons). But really -- this ad image is a wonderful example of jpeg artifacts and why you can't just turn the quality down arbitrarily far.

I could even understand using extreme jpeg compression because they were sending out a hundred quotillion spam messages and wanted to reduce bandwidth. But they're not sending a jpeg -- they've converted the low-quality JPG back to a 348Kb PNG before sending the spam.

All I can figure is that someone designed the ad and saved it as JPG, making it really small. And then someone in the business saw lbrandy's great cartoon on JPG vs. PNG -- and said "Oh, no! We'd better use PNG instead! And loaded up the JPG and saved it as a PNG with default settings.

(For further reading on PNG vs. JPEG and image file size optimization, you can get an overview of formats at my Image Formats for the Web and some detailed tutorials at the Bandwidth Conservation Society; or chapters 2 and 8 in my GIMP book, soon to be out in its second edition.)

Tags: humor, advertising, gimp
[ 10:54 Nov 14, 2008    More humor | permalink to this entry ]

GIMP Drag-n-Drop and Open Location without gvfs

Quite a while ago I noticed that drag-n-drop of images from Firefox had stopped working for me in GIMP's trunk builds (2.6 and 2.7); it failed with a "file not found" error. Opening URIs with Open Location also failed in the same way.

Since I don't run a gnome desktop, I assumed it probably had something to do with requiring gnome-vfs services that I don't have. But yesterday I finally got some time to chase it down with help from various folk on #gimp.

I had libgnomevfs (and its associated dev package) installed on my Ubuntu Hardy machine, but I didn't have gvfs. It was suggested that I install the gfvs-backends package. I tried that, but it didn't help; apparently gvfs requires not just libgvfs and gvfs-backends, but also running a new daemon, gvfsd. Finding an alternative was starting to sound appealing.

Turns out gimp now has three compile-time configure options related to opening URIs:

  --without-gvfs          build without GIO/GVfs support
  --without-gnomevfs      build without gnomevfs support
  --without-libcurl       build without curl support

These correspond to four URI-getting methods in the source, in plug-ins/file-uri:

• uri-backend-gvfs.c
• uri-backend-gnomevfs.c
• uri-backend-libcurl.c
• uri-backend-wget.c

GIMP can degrade from gvfs to gnomevfs to libcurl to wget, but only at compile time, not at runtime: only one of the four is built.

On my desktop machine, --without-gvfs was all I needed. Even without running the gnome desktop, the gnomevfs front-end seems to work fine. But it's good to know about the other options too, in case I need to make a non-gnomevfs version to run on the laptop or other lightweight machines.

Tags: gimp, desktop, performance, gnome
[ 11:09 Oct 31, 2008    More gimp | permalink to this entry ]

Fast Pixel Ops in GIMP-Python

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 ]

GIMP for middle school kids

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 ]

Quick GIMP Tip: Middleclick to open images

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 ]

Easy layer mode changing in GIMP

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 ]

GimpLabels: Printer fudge factor

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 ]

Getting a Wacom Tablet Working under Edgy

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:

1. Install wacom-tools and xinput
2. Edit /etc/X11/xorg.conf and comment out those ForceDevice lines that say "Tablet PC ONLY".
3. 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 ]

GIMP JPEG 2000 Plug-In

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 ]

GIMPing a "favicon"

"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 ]

Slashdotted!

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

Beginning GIMP

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 ]

New Pandora, Reversing Layers, and Script-Fu Booleans

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 ]

"Beginning GIMP" is shipping!

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 ]

Pandora Now in Script-Fu

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 ]

Quick GIMP Tips: Centering a Layer, or Preventing Centering

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 ]

The GIMP Book is Done!

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 ]

What Features will be Disabled in this GIMP?

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 ]

Using GIMP for Paper Prototyping

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 ]

Switching from Debian to Ubuntu; Dependencies To Build GIMP

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 ]

GIMP Menu Reorganization

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 ]

Wacom Rides Again

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 ]

GimpLabels script-fu

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 ]

GIMP course started

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 ]

Pandora 0.7 released

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 ]