William Skaggs wrote: > First, it's not clear whether you are bothered by the resources > Gimp consumes in creating lots of layers, or by the nuisance of > managing them. If it's the former, don't worry about it: text > layers are very lightweight, and you can create hundreds of them > without putting much of a burden on Gimp. If it's the latter, that's > a different story. At some point Gimp will get the ability to > group layers together and collapse the groups in the Layers > dialog, but not quite yet. That will be great when it happens. The short-term problem is that the files I generate are very large (12,500 x 2500 pixels x 15 layers that I need to access easily). Here's the example that I'm currently working with: -rw-r--r-- 1 skod staff 188878323 Jun 29 10:08 image.xcf That's not a typo... In any case, stacking up a large number of text layers on top of the layers with the graphical info I need is a bit painful. And you can imagine that major layer manipulations on layers that large can be very resource-intensive. A simple save of that file takes 4 minutes and 20 seconds. Since yesterday, I've found a couple of useful workarounds: First and most importantly, do *not* create an empty full-image-size layer for the text before adding it in. Doing so was required in the old Gimp, but in the new one it makes the merge with the many tiny layers that get created with each 2- or 3-letter annotation very slow. Instead, just add text and repeatedly merge so that only the first new text layer is retained, dynamically growing with each merge. This makes the rendered text layer (significantly!) smaller than the entire image size. The smaller dataset helps keep Gimp away from the swap thrash that it would otherwise encounter, and makes the merges remarkably faster, especially when first starting the annotation process. That might be worth mentioning in the doc... Secondly, merge all the text layers every 30 or 40 annotations, *especially* before attempting to pan the view into a new area of the overall image- also to minimize the overall data structure, presumably make viewport clipping easier, and avoid the swap thrash. Minor aside: dynamic key bindings are a godsend. I long since bound the merge-down to lowercase L on the keyboard, and I'm getting a bit more used to it now... Due to the enormous datasets I need to work with, I seem to be constantly running right up against the thrash limits of the tool (tile cache set at 256Mb on a machine with 1Gb physical memory). It's the nature of the work I do. The bottom line is that I'm probably working with slightly larger images than the average user. Time for a dual-2GHz G5 with 4+Gb of main memory, I think. Nothing succeeds like excess! > The best suggestion that I can think of, if you really want the old > nasty behavior back, since your situation is probably so unusual as > not to be worth supporting in the core, is that it would be possible to > write a plug-in that would behave more or less like the old text tool: > you would make a selection, activate the plug-in, a dialog box would pop > up allowing you to type some text, and when you press Okay the text would > be written onto the image at the site of your selection. I might have to work on that at some point soon, once I can get this dadgum paying work out of the way. Coding is not my primary forte, but I'm sure that there is some unsuspecting plug-in out there that I could shamelessly plagiarize as a framework. My needs are pretty simple here- black text in 10-pixel Helvetica in the currently selected layer will always work for me, for example. It could even auto-anchor: I don't even need to be able to move it after it is placed. Or if I do, I'll select it as a separate action. Still, I'll bet that I'm not the only stick-in-the mud out here. (;-) There are technical applications for this tool, like mine, that far exceed what it was probably intended to do at the outset- and are probably orthogonal to the original authors' intentions. And there are probably other nerds like me that will run aground on this, and will wish for the old nasty behavior. If it isn't too painful, it might be worth considering a backwards compatible mode, even though it is ugly... The true magic of the Gimp is that it works as well as it does on these enormous datasets. Thanks for the quick responses! All help is appreciated. -skod -- Scott Griffith ISES-LLC 9745 Steeplechase Drive Franktown, CO 80116 303-660-2541 303-660-2542 fax skod@xxxxxxxxxxxx
