Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
The Gimp

What's Ahead For The GIMP? 157

Posted by timothy from the or-rather-what-isn't dept.
Ur@eus writes "Hi, We have just interviewed Sven Neuman, lead developer on the Gimp. The interview covers the upcoming 1.2, 1.3 and 2.0 releases of the Gimp and how [they]will evolve further. You will find the interview here" Improved path support, GIMP/GNOME interaction and an improved rendering system are a few of the points that Sven addresses -- The GIMP has impressed for years and keeps getting better.
This discussion has been archived. No new comments can be posted.

What's Ahead For The GIMP? More

What's Ahead For The GIMP?

Comments Filter:
  • Ah. Sorry 'bout that; I don't do much graphics work, so I didn't catch that the Gimp doesn't do that. You'd think it wouldn't be that hard to implement.....

    --

  • Hmm, actually, now that you mention it, it would be interesting to compare Photoshop on Mac OS vs. Gimp on, say, YellowDog or TurboLinux, on identical hardware.

    --

  • Why does everybody always pick stock installs of RedHat for these tests? I'd much rather see the test done on a better distribution with some normal configuration tweaking, vs. Win98SE with reasonable tweaking. I mean, I hope you're not doing graphics benchmarks with Sendmail, Apache, and a gazillion other daemons running in the background?

    No extra optimizing software should be installed, though. Just changing the configuration of the software that the distribution comes with.

    --

  • when the local art collage asked me to teach a photoshop class, i asked if i could teach gimp instead. no.
  • on irix, glDrawPixels is the fastest way to get an arbritatry frame buffer to the screen (unless you store your arbritrary frame buffers in texture memmory) but this is only true of irix. most other gl implementations are slower. thats probably why erdas is so fast in comparison.

    using open gl for the gimp would be easy, its a simple call, but it would slow the gimp down for most platforms. maybe an #ifdef FAST_GL would be a good thing...
  • AbiWord simply links directly with the Windows API present on all Win32 installations. For each platform AbiWord supports, it uses the native widget set (where Unix's native set is GTK+). This keeps the interface snappy and the overall feel complete. There are advantages to using one single toolkit across platforms (like GIMP does): very little work to support a new platform (as long as it supports the toolkit). Using a cross-platform class framework (like wxWindows) is a great idea when the classes match the functionality you need. AbiWord needs to do so much pixel twiddling (which can be made cross-platform at the device context level) that using cross-platform toolkits doesn't win us as much.

    --
  • gotcha. That sounds like a fairly straightforward change to gimp. As far as having lots of windows open, at least for gnome, you can configure the MDI (multiple document interface) behavior: each-in-its-own-window, modal-with-tabs, or modal-without-tabs. Of course, you don't just want to apply it with an iron fist. You really want grouping: all these windows should be modal-with-tabs, but then using each-in-its-own-window for groups. It'd be cool if you could drag a -its-own-window to a tabbed window and have it swallowed up. Dunno if gnome does that.
  • Indeed.


    --Phil (channel!)
  • They support Japanese, as I've used the Japanese version on my own computer.

  • I recently upgraded from 1.2 to 1.0 because I needed to use the mosaic effect on something, and it wasn't present in the version of 1.2 I had. Will they be putting it back in anytime soon?


  • no shift!!
    --
  • Someone needs to merge that 16 bit branch into the main source tree.

    Just so you know, that is 16 bits per channel. That's more colours than your video card handles, in all likelihood. And yes, it looks like it will be merged in.

  • Does it have a better UI? I'm not keen on programs that have a lot of little windows floating around. It takes me ages to remember which window I need to click on to get the context menu I need, including finding it in amonst my other programs. I think the GIMP is great. If only it were just had a nicer UI for those of us who only use it occasionally. I was also very happy to discover a Win32 port recently.

  • This is very likely an X configuration issue, as I'm a lazy ass and haven't bothered tackling it, so the number pad Enter doesn't even work in Netscape or Xterm....

  • In fact, having no video card at all would give you much better results and, obviously, save you money.
  • Did you read the article? The GIMP is going to be ripped apart and recoded from scratch after 1.2. 1.2 is "close" to being released. To me that says that the GIMP is going to be recoded from scratch "anytime soon", but I'm not an idiot, so what do I know?
  • Gimp 1.1 has layers, channels and paths. Are there things you can't do with these in the GIMP that you can in PSP?

    --
    "Where, where is the town? Now, it's nothing but flowers!"
  • no!
  • The GIMP will take off when the UI is fully customizable; Making the UI maximally customizable should become the GIMPs next great goal.
    This is actually a highly achievable goal with the help of libglade [freshmeat.net].
  • For what its worth that wine wrapper xmms plugin was for vqf, it might be a nice example of how to achieve something like that. A very impressive hack [slashdot.org]

    C.

  • Some more informative answers:
    1) Yes, X supports multiple inputs, I use the nipple pad on my IR keyboard and a mouse. Here's some relevant XF86Config lines:

    Section "Xinput"
    SubSection "Mouse"
    Port "/dev/ttyS1"
    DeviceName "Second Mouse"
    Protocol "Microsoft"
    AlwaysCore
    EndSubSection
    End Section

    AlwaysCore lets it control the main mouse pointer (as per in the standard Pointer section of the config)

    Ditto for stylus, the appropriate SubSections are probably commented out in your XF86Config already, if you use xf86config to generate it. I know Wacom has plenty of support, although I don't have one myself. I know GIMP has pressure sensitivity, I _think_ it has tilt/roll and erasing. I don't own one myself, but I know someone who does, and uses GIMP 1.2 prereleases with it.

  • There are three major efforts in progress... I don't use Adobe Illustrator, and I basically use vector graphics tools for basic layout stuff and maps, so I can't comment on how far they really are, but...

    1) Sketch [sourceforge.net]. It's been around a long time, and uses Python/Tk (Python/GTK in the unstable version). It has quite a few features, but the unstable version as a GIMP-like interface, and I know some people don't like that (personally, I love it). It does illustrator, svg, and it's own sk format for import and export.

    2) Sodipodi [sourceforge.net]. It appears to be built on a slightly better designed codebase than Sketch. It uses SVG as a native format. Biggest thing it appears to have going for it is full 8 bit alpha channel.

    3) KIllustrator. Part of KOffice, it has a crapload of import filters. Sketch outdoes it, IMO, but KDE always suprises me in one way or another.
  • Heh, err. Dealing with the alpha channel is easy--however, you first have to add the alpha channel. Somewhere in the Image menu should be "Add alpha channel", not sure what submenu. Then you use the Eraser tool (probably other tools you can use to apply transparency) to reduce the alpha channel. Plus take a look at the brush dialog; it lets you set the opaqueness for the brush, plus with Layers, you can use transparency (or even image opaqueness) to blend the layers together.
  • Nope. Not unless you either port one or back-engineer it. Some have been back-engineered, but there's a long way to go.

    one hope I have is that Alien Skin will eventually port to GIMP. that would just be amazing.

  • I have run this thing on a bunch of computers,
    some of them pretty fast, and the fuzzy select
    tool is so amazingly slow it is unusable.

    Any work being done to address this?
  • why dont people get the idea "DO NOT REINVENT THE WHEEL"

    Throwing out your old nasty code so you can rewrite it isn't called "reinventing the wheel". It's called "throwing one away" [st-and.ac.uk]. Yes, GIMP 2.0 might take longer to be released. Provided they don't go crazy and decide to make an "application platform" instead of the thing they're supposed to be making, it could actually speed up development, because the architecture should be cleaner and easier to understand. Besides, the GIMP code isn't nearly as nasty as the Netscape code was.

    Maybe you're referring to the fact that GIMP is an image manipulation/paint program, and there are lots of those out there. Not many of them are scriptable though. Very few run on Linux. Even less are open source, and let you make your own tweaks/bugfixes/improvements. Plus it's free (as in beer -- I covered the other free in the previous sentence). These attributes together make the GIMP useful and valuable to some people. If it had no unique qualities, then maybe it would be "reinventing the wheel". But that isn't the case here.
  • First off, filters don't detract from the GIMP, as another person mentioned it is not the same people writing core and plugins.

    As far as the list of features that you mention, I think someone else also made a good run-down of where they stand. I just want to point out that Photoshop did not have ANY of these features (except maybe magnetic selection) until version 5.0. That was just a year ago it came out. Now GIMP is in a similar in-between major revisions stage. As is usually the case, open-source trails slightly behind commercial products in some areas. But other features (multi-level undo) have been around for quite some time.

    LoppEar
  • Even Windows Paint has a line tool, and even a circle and a square tool to boot. But I guess an image manipulation program is only supposed to manipulate existing images that were created in Photoshop.

    I'm probably out of touch cause I've only used 1.04 and earlier versions. If they haven't added such shape tools to the 1.1 or 1.2 then I hope they keep taking their blue matrix pills each night.

    "I can only show you Linux... you're the one who has to read the man pages."

  • One reason Photoshop is regarded as suitable for use as industrial machinery is that Photoshop has the Pantone colours built in - licenced from Pantone. Is there any way to get these into the Gimp? A licenced plugin or something?
  • How hard would it be to add vector support to the Gimp? It would be really cool to be able to mix rasters and vectors between frames in the same image, and I don't think it would be impossible, either. The infrastructure probably exists already, since Dynamic Text is a vector. You'll notice, in the Layers palette, that Dynamic Text is its own type of layer, with the properties of vectors - resizability, etc. Any idea of the difficulty of adding more sophisticated vector support in the future? Even mixed raster-vector layers, perhaps? Raster-tiled vectors? Vector shapes with complicated, super-level defined properties (e.g., "Draw a capital Q, and then perform a [raster-based] chrome filter on the resulting raster)? 'cause that would be awesome, and it would be a feature that no other program would have, to my knowledge. Certainly not Photoshop.
  • The Gimp has a line tool. Try clicking with the pencil or brush or whatever and holding shift, and then clicking again, somewhere else.
  • http://www.gimp.org/~tml/gimp/win32/
  • What was that web page that was based on gimp, that enabled browser based image manipulation via gimp? There was a /. story on it earlier, but I can't find it.

  • I think that you are confusing two things: wavelet coding of an image and hierarchical editing. Wavelets should can be useful for the final output (saving the final image as JPEG2000), but they should not be used as the internal representation while you are editing the image. You cannot (in most cases) mix wavelets and lossless editing.

    On the other hand, some kind of hierarchical editing can be interesting if you are working on huge images. It could be implemented by extending the current concept of layers in the GIMP, and it would not even require a major re-write of the plug-ins and tools. If I have too much spare time (cough!), I may even consider implementing this for version 1.4 or 2.0.

    The only thing that would have to be done is to allow the layers of an image to have different resolutions. So the background layer of the image could be stored at 300dpi while the other layers are stored at 2400dpi. Most of the plug-ins and tools work on one layer at a time and are independent of the resolution of the image, so they would not have to be modified. Some other operations such as "Merge visible layers" or "Bump Map" would have to be re-written, but it should not be that difficult.

    But I am not sure if there would be a big advantage in doing that. You would save some memory, but several operations (including displaying the image) would be slowed down because it would be necessary to check the resolution of all layers and to re-scale them at the same resolution before merging them.

  • Here are some answers to your suggestions:

    • Vector layers. They are no there yet, although this has been discussed several times among the GIMP developers. The current implementation of paths (using the bezier tool) is already using some vectors and the FreeType plug-in [gimp.org] can convert text to paths, but this is not exactly what you want. Note that you can apply some basic transformations to the paths (rotation, scaling, shearing), but the support for vectors in the GIMP is still limited. Currently, if you want to work with vectors, it is better to try Gill [levien.com], the GNOME illustration app. Maybe Gill and GIMP could be merged in the future?
    • Non-linear history. This has also been discussed several times, and this will be part of version 2.0. This was even mentioned on a page [gimp.org] that the article refers to.
    • Line tools. Did you know that you can already draw straight lines, circles, squares and other shapes with the GIMP? To draw a straight line, select any painting tool, click where you want to start your line, then hold shift and click a second time. To draw a circle or a square, use the corresponding selection tools to make a selection, then use Edit->Stroke. The latest development version of the GIMP contains some tips explaining how to do that easily. You can even do some exotic things such as drawing lines with a gradient or with a fading brush.
    • Dynamic seletors. Well, I am not sure that I understand what you want. I would be interested in more details...

    Many things are already possible with the upcoming version 1.2 of the GIMP. I suggest that you have a look at the tips and on-line help that are distributed with the current version, or that you have a look at some of the recent books, such as Grokking the GIMP [gimp-savvy.com] or the GIMP handbook by Sven.

  • Hey Sven, it's better if you include a link to your great FreeType plug-in. :-) Here it is: http://freetype.gimp.org/ [gimp.org].

  • In playing around with Gimp I haven't seen any kinds of utilities that even approach this level of web graphics functionality. This may be due to my ignorance in using Gimp, so I may very well be judging too harshly here.

    Some parts of the user interface should definitely be improved, and hopefully this will be easier to implement in version 2.0. I don't think that any of the current developers would implement the full range of features of "Save for Web" or ImageReady in version 1.x. However, some of the features that you are looking for are already there. For example:

    • If you save an image as JPEG, you can see a preview and adjust the quality of the image.
    • To split an image for web use, you can try the Guillotine or Perlotine scripts (Image->Transforms->Guillotine or Image->Filters->Web->Perl-o-tine). They split an image along the guides and the second one will output the HTML table for you.
    • You can easily create or modify an image map using Image->Filters->Web->ImageMap. It creates or modifies the HTML code for you.
    • Several scripts and plug-ins allow you to create animations easily. For example, try Image->Filters->Distorts->IWarp or any of the scripts in Image->Script-Fu->Animators. You can preview and optimize your animation with Image->Filters->Animation->Animation Playback and Image->Filters->Animation->Animation Optimize.
    • If you want to create more complex animations involving several moving objects in multiple layers, there is a whole set of GAP plug-ins available under Image->Video.

    These features could be integrated a bit better and presented in a way that even new users find them easily, but they exist already. One thing that could be improved in the future versions is the "Export" feature which could include some features of "Save for Web": for example, a preview for GIF and PNG (not only JPEG) allowing you to change the number of GIF colors easily and compare the results with the original.

    Last point: When I'm doing some serious editing inside of PS I find myself playing the keyboard like a piano. After a number of years working with it, my mouse and keyboard hands work independently switching between tools and using them. I have a feeling that a lot of serious PS users work in a very similar manner. I don't believe that Gimp should strive to just be a PS clone, but it would be helpful to a lot of PS users such as myself to perhaps provide a loadable keyboard mapping that equates back to PS.

    It is already there: look for a file called ps-menurc in the top-level directory of the source distribution. If you install this file in your ~/.gimp directory, you will get the same keyboard mapping as PS.

  • About more dynamic selection tools... a better selection representation would be good, especially with regards to feathered selections and stuff... Maybe a sort of 'convolve' tool to selectively feather particular edges of a selection would be good. Maybe something else to 'nudge' selection areas... as in push the border in and out but retain some level of connectivity - sort of moulding tool for selections.

    I see... What you want is the QuickMask feature that is available in the latest releases: by clicking on the little square buttons that are in the bottom left corner of the image, you can activate the quick mask which allows you to view your selection as a semi-transparent mask and to edit it with the usual painting tools. When you are satisfied with the result, you can click again to convert the mask back to a selection. I think that it does exactly what you want.

    oh and I would like to see brushes displayed something like selections are, so that you can see your brush edges.

    This has been discussed several times on the developers' mailing list. Unfortunately, some limitations of the X Servers make this feature much more difficult to implement than it seems. Basically, it is difficult to create a cursor that is larger than 16x16 pixels, which is obviously a problem for most of the brushes.

  • Also is there any way to interface the GIMP's plugins/script-fu to a web server to use as CGIs? On the fly generated images would be mucho cool.

    See www.cooltext.com [cooltext.com] for an example.

  • See Canvas (www.deneba.com). Also available for linux.

    -c
  • Does the GIMP currently have (or likely to add in the very near future): editable text layers, layer effects, in-layer text editing, magnetic selection tools, multiple-level undo, integration with optimising tools, etc?
    • Editable text layers: yes.
    • In-layer text editing: ...not sure of the status on this one.
    • Magnetic selection tools: Selections may snap to guides, is that what you mean?
    • Layer effects: We do have different layer modes (multiply, overlay, value, etc). We do not have things like "drop shadow layers".
    • Multiple-level undo: has been there for at least three or four years.
    • Intergartion with optimizing tools: Not quite sure what this one refers to.
    Don't waste time with so many plug-ins and filters, and refine implementation of the fundamentals. The plug-ins should be a later priority.

    The thing is, it's not mostly the same people working on the plug-ins as are working on the core. A plug-in is relatively small and easy to control, so individuals can pick whatever effect they're interested and go do a plug-in for it. These are not usually the same people who have working knowledge of gimp's more complex internals...

    Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ [sourceforge.net]


    --

  • Photoshop plug-ins like AlienSkin can't be used with gimp. However, the "Filter Factory" filters (.afs and .8bf) files can be used with the User Filter plug-in [geocities.com].

    --
    Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ [sourceforge.net]
    --

  • Someone else started a SourceForge project with the intention of doing this. I haven't seen many signs of life from over there lately, but you could try waking them up...

    piGIMP [sourceforge.net] is a project to benchmark GIMP against Photoshop...

    I also think that rather argue about the video card, it would be more productive to come up with a benchmarking suite, to decide what and how the benchmark will measure instead of where.


    --
  • Hence we have Gimp (Gimp is my photoshop)

    Eek! This is not what GIMP expands to. Rather, it is the GNU Image Manipulation Program. In some times past, people have used the "G" for "Graphical", but the "P" has never been Photoshop.

    Opinions on how to capitalize it [oberlin.edu] are varied.


    --
  • How many people are working on this thing. Is it just the original creator??? Will they have to hire a larger team when they hit the "releasable" 2.0?

    The "how many people" question is answered by Sven in the interview, I think. As for the original creator, well, that's an interesting story [gimp.org]. And "will they hire a larger team"? Umm, AFAIK, no-one (including distributions and start-ups) has any programmers on payroll for GIMP at this time, so I'm not sure who would be doing the hiring...


    --

  • You are correct in thinking that such a thing would have to be licensed. The phrase I hear most often for Pantone support is "patent minefield". Such a thing would be pricey, and would require a commercial sponsor with deep pockets, and the resulting plug-in would be non-free... So far, no one's offered to sponsor this.


    --
  • Created for just such occasions, the Straight Line Tutorial [gimp.org].
    --

  • The Tile Cache Size is in the "Environment" section of the Preferences dialog. It should be set to about as much RAM you system is ready and willing to dedicate to GIMP.


    --

  • As has been answered above, the GIMP does not have all of that at all. It doesn't have in-layer text editing, magnetic selection tools, or optimising features (like FireWorks and ImageReady).

    If it doesn't have these specific features, then it obviously can't do "a lot of that much better than Photoshop does".

    A simple save of a PNG (or some other horrendously unsupported image format perhaps?) does not count as an optimising tool/feature.

  • I am a longtime and frequent Photoshop user (ie, any number of hours per day). I use the standard Photoshop filters, and even then - only a few of them. I tried Alien Skin and Kai's Power Tools and Swt-Flux when I first started using Photoshop, and have long since uninstalled them.

    When I first saw The GIMP, I laughed at the number of filters - it was ridiculous.

    More and more filters won't bring more people to the GIMP - if they won't use it, it's because it's just not Photoshop. The interface isn't the same. When I tried it briefly a few months ago, it felt flaky and I hated it.

    That, coupled with the fact that every call for graphic designers in the employment pages asks for Photoshop knowledge, and the GIMP faces an incredibly hard battle to build acceptance amongst designers.

    Does the GIMP currently have (or likely to add in the very near future): editable text layers, layer effects, in-layer text editing, magnetic selection tools, multiple-level undo, integration with optimising tools, etc?

    Don't waste time with so many plug-ins and filters, and refine implementation of the fundamentals. The plug-ins should be a later priority.
  • How on earth is this overrated? Someone is just looking to avoid being meta'd to death, or at worst is targeting me personally. WHY!?!!?

    I have a few clients who USE this kind of software, and my point about commercially available training *IS* based in fact! The last person I setup I WANTED to setup with the GIMP, but she knew photoshop and didn't want SEVERAL more books! Not EVERYONE is a geek who can just "RTFM" and off they go! If I could have sent her to a CLASS in using the GIMP, then that would have been different - HOW is this observation over rated?!?!?!?!

    Fawking Trolls! [slashdot.org]
  • The process is quite complicated, and results vary quite a bit between various implementations. The reason for this is that with CMYK uses 4 channels: cyan, magenta, and yellow (inverses of RGB), and also the key (usually black). For example, the color black can be made either by setting the key channel to 100%, or by setting C, M, and Y to 100%. While converting RGB to CMY without a key is trivial, deciding how much key to put in various combinations can be quite painstaking to get 'close to perfect' results.
  • The Gimp has yet to remotely compete with Adobe.

    Yeah. Sure. Lots of people, myself included, use the Gimp to create quality images. To say that the Gimp doesn't "remotely compete" is ridiculous.

    I personally do not make use of Photoshop's higher-end capabilities, such as the prepress capabilities. But, for what I do (mostly creating graphics for web pages), the Gimp works just as well, or better than, Photoshop does.

    I guess there is one area where the Gimp doesn't even remotely compete with Photoshop - price. The full version Photoshop, last time I checked, sold for well over $500. While the Gimp may not be able to do everything Photoshop can, it's available to anyone since it's free software. There's no "Limited Edition" of the Gimp - the one, full version is an excellent value at a price of absolutely nothing.

  • I don't know the specifics, but I seem to remember that there is some buffer setting in the config files that you can increase to make working with large images more efficient.

    If you can find it, you might want to crank it.

    -Mike
  • I've run them both in on various systems (umm although I don't actually have anything as good as your 'low end' one), and generally all things being equal photoshop is faster, especially for applying filters. Like them both though and don't particularly care if one is faster, they work in different ways and hence lead to different ideas and designs.

    Anyway off to see if I can eat an apple or a pear faster. . .

  • rpm -qi glibc and see what the version is...
  • Ahh Gimp Lite you mean?, unfortunately it is entirely impossible for them to do this, as since the full version is already free they would actually have to pay you to have it included with your scanner/printer etc. . .
  • Please tell me they are considering using an internal LAB color model :) that's one of the key points about Photoshop that makes its images better than RGB stuff- LAB is a broader color gamut than RGB. My understanding is that Photoshop uses LAB as an intermediate stage when converting from any color model to any other (bar grayscale, or indexed).
  • Hi,

    You may be interested in a critique of the UI that I did:

    http://www.snowdrift.org/computers/gimp-crit.htm l

    The response was not entirely hostile, but the fact remains that 'code it or go shut up' still rules. Programmers are not willing to see themselves as implementing a good idea they didn't think of, certainly not willing to implement a good idea they don't agree with.

    This is why non-free software doesn't have too much to fear yet. Meanwhile I've started to join in with KImageShop in the hope I can talk them round to at least thinking hard about the UI with UI hats on and not programmer hats on.
  • I use gimp for post-processing of images of satellite data generated with Erdas Imagine [erdas.com]. A typical satellite image might be 20k X 9k pixels, 32bits per pixel, 6 bands of data (4GB!!). Obviously we need to do the image processing at this resolution (to prevent scaling effects) but frequently we need to also output at this resolution - for large maps, posters etc on a roll plotter.

    Erdas Imagine can easily pan, zoom and manipulate an image this size - yet GIMP on the same hardware (SGI O200) becomes virtually unuseable.

    Imagine does this by storing several copies of the same image at different screen display resolutions in it's proprietary image format. If the same thing was done with gimp and XCF files, it would make my life a hell of a lot easier.

    Nick

  • I thought too that that would help, at first. But that menu only applies to your most-recently-created window, which is more confusing than helpful.

    --

  • It doesn't quite go that far. The thing is, the menus don't start in a fixed place, but rather are all context menus that pop up when you right-click on your image.

    Context menus are great -- if they're short. Long lists there (especially with multiple levels of submenus) really slow things down. A better way to do it would be to use the context menu for a few common features, and put the rest on a menubar. An even better way to do it (in my humble non-mac opinion) would be to make the right mouse button do something related to the tool selected (like draw in the background color?).

    --

  • This has been around for yonks, for as long as I remember using the GIMP (pre 0.99). It's called Net-Fu. I don't know if it's being maintained anymore. It is in the directory at the GIMP site:

    ftp://ftp.gimp.org/pub/gimp/net-fu/

    Some sites using the GIMP/net-fu as a backend are:

    http://www.onlinephotolab.com/

    http://www.cooltext.com/



    --
    "Where, where is the town? Now, it's nothing but flowers!"
  • I've always wondered, shouldn't it be a simple function to convert RGBCMYK?

    No, it's not. There are some simple algorithms to give you an close approximation, but that's not good enough for prepress work. The conversion needs to take account of the characteristics of the output device, such as the gamut, amount of ink bleed and so on. Yes, you can do it without worrying about these things, but the colours won't look as good in the final printed image.

  • Actually I would rather see floating point support. Truncating the mantissa of 32-bit floats so they are 16 bits would actually be a much better use of 16 bits, allowing far higher resolution in the darker colors, where the resolution is needed.

    An extra bit of resolution could be achieved by shifting away the sign bit before truncation. (negative colors are not needed).

    Better dithering algorithims are much more important to getting a good representation than throwing more bits at it. The vast majority of popular image file formats are 8-bit only, so a good converter to 8 bits is more important than handling 16 bits. A 16-bit file is likely to be run through a bad 16->8 converter, resulting in a *worse* result than if Gimp produced 16 bits.

    A png-like standard that saves the exponent with reasonable compression would allow "lossless" storage.

  • Gimp-2.0 will be a total rewrite. This doesn't mean that we will not reuse any code from the current codebase, but we want to change the basic architecture and build the most advanced image processing system out there.

    This sounds like a good plan to me. It would be really nice to be able to write scripts that run GIMP and execute efficiently. For example, if you're making images for a website, you probably want your "source" images to be in xcf (gzipped or bzipped probably), but the "published" images need to be in GIF, JPEG, or PNG. Having a script (or Makefile...) that would tell GIMP to produce the published images whenever the "source" images change would be incredibly useful. This is somewhat possible today, but GIMP has a very long startup time (so invoking it once for each image is not a good idea), plus it seems to be really unstable when running in batch mode.

    Doing a "complete rewrite" will also make it easier for more developers to get involved. It's always hard to get into the code of something that's been around a while and has accumulated significant bloat. (I'm not saying that GIMP is particularly bloated, but all projects tend to "fatten" with time)

    BTW, has anyone else tried to get involved in GIMP development? Whenever I went to the GIMP IRC channel to ask some GIMP development questions, people always seemed really reluctant to talk about development, and instead just wanted to talk about random subjects. Where's the place to talk about GIMP development?
  • Please check the reference that I gave before speculating. Non-lossy wavelet representations for editing are straightforward, and they are fast and useful. (They are also very different from having multiple layers at different resolutions, the strawman you shoot down.)
  • Menus that you don't have to look at are a good idea; linear menus are not the best choice--circular menus are. And people can even make selections pretty reliably in multilevel circular menus.
  • I'm not a graphics person or a programer but I do test and follow the mailling list of a lot of OSS software. (Wine, Kernel Notes, Hurd Etc)

    I was wondering if one might be able to use photoshop plugins in the gimp if someone port like a wine wraper for certain files or even did something like what was done with xmps with the Windows DLL.
  • Pie menus! Pie menus! They need to incorporate the GTK pie menu widget into GTK and use it in GIMP! Sorry. Pie menus on the brain.

  • What you want to do is to increase the "Tile Cache Size" (in File->Preferences/Environment) to a value that as large as possible. Set it to a value that is close to the amount of physical RAM available on your system and the GIMP should work much faster. The recent 1.1.x versions of the GIMP (soon to be 1.2) include a nice dialog box that pops up during the installation and explains how to set up this value.

    But that would only solve a part of the problem: it would still take time to refresh the image during panning operations if your the factor is 1:8 or 1:16, because the GIMP has to fetch every 64th or 256th pixel in the original image before drawing it. This leads to cache misses in the CPU, and the coordinate scaling requires some additional operations for every pixels that is drawn. As explained in other comments, some programs are storing temporary copies of the image at various resolutions in order to speed up the panning operations on zoomed-out images. The advantage is that you can move around faster, the disadvantage is that these temporary views have to be re-computed every time you change the zoom factor. The GIMP is fast when zooming in/out but slow at redrawing large images. Other programs are fast when panning a zoomed-out image, but slow if you want to change the zoom factor.

    As with many other things that involve a tradeoff between CPU cycles and memory, this should probably be configurable. Yet another idea for version 2.0...

  • Personally, I'd like to see a set of trials and benchmarks betwen the GIMP and Photoshop. For best results, it'd be nice to see them compare on both high and low-end systems.

    I'd reccomend, for example:

    Test suite #1: Linux System:
    Redhat 6.2 default installation (no tweaks)
    Window System:
    Windows 98 Second Edition default installation (no tweaks)
    Hardware:
    Sawmill window manager (small and fast) PIII dual 650 MHZ w/ 512 MB Ram (to avoid AMD windows issues [if any]) A good Gforce2 vid card.

    Test Suite #2:
    Same as above but with a PII350 w/ 128 MB RAM.

    True, we'd never know if it was Windows vs. Linux or Gimp vs. Photoshop, but it'd certainly be fun. I, of course, would expect the Gimp to come out on top but ya never know ;)

    Cheers,
    DranoK



    That is not dead which can eternal lie, and with strange eons even death may die.
  • I've always wondered, shouldn't it be a simple function to convert RGBCMYK? Is there anything I'm missing or is this a simple conversion?

    --Ben

  • Two pages: info [gimp.org] and downloads [gimp.org]. It's still sketchy on the stability side of things, but if you don't have several hundred dollars to shell out to Adobe, then it's all you've got.
  • This feature has been around in The GIMP for ages.
  • There is a windows port of GIMP that uses GTK+
    located at: http://www.gimp.org/~tml/gimp/win32/ [gimp.org]

    most of it works, except for some random crashes ;-)

  • I would love to see something in gimp that lets you create vector layers. Some layers can be totally pixmap and some can be vector or even mixed? Also, a non linear history like PS would be wonderful... it might allow you to actually apply filters to vector bits but still be able to treat the object as a vector chunk. Make sense? You could then do filters on text and stuff, but still go back and edit the text content. I'm still missing the line tools as seen in photoshop, and some really cool dynamic selector tools would be great - maybe some sort of connect the dots style selector?
  • First I have to say that I am completely pro free software on the internet and I appreciate everything that the Gimp stands for but: I have tried many graphic programs including PSP and Photoshop as well as Gimp but there is something about gimp that is straight up awkward! I can't seem to get the feel of it. Knowing your software in very important when working with graphics.

    A complete rewrite may fix these issues.

    The second thing is that if I was to use Gimp there would be no reason for me not to use Linux which then causes a new issue; I don't know what it is maybe it's my settings but I can't work well with my mouse in a linux environment I think it has something to do with the refresh rate. Now why I use ImageMagick instead of gimp for web based is as simple as this.. ImageMagick gets to the point gimp on the other hand (as convenient as it may be for some people) has way to many advanced features which then makes it way more complicated than it needs to be or than I want it. Also the support for CMYK.

  • I use Photoshop every day. It's a critical application for me, for pretty much any and all art tasks, both for fun and profit.

    I pose the following as questions. Perhaps all of these are possible today in the open-source world.

    • Can Enlightenment or X deal with more than one device controlling the onscreen pointer?
      In Windows and on Macs, if you leave the mouse alone, you can use the pen or puck to click. If you leave the pen or puck idle, you can move the mouse to click and drag around the filesystem quickly. You don't have to select anything to switch. (Some Windows laptops get confused between plugged mouse and touchpad, but pen tablets and mice have mastered this co-existance long ago.) You can't draw freehand with a mouse anywhere near as well as you can with a pen, and conversely, a pen is unwieldy when double-clicking small gui elements.
    • Does Linux or GIMP support extended information from the pointing device?
      Pressure sensitivity is only the tip of the iceberg here, but it is a WORLD of difference over a fixed stroke. Press lightly, thin hairline. Press heavily, bold swath. All in one stroke. Modern pen tablets understand many variables and can forward them to any interested software: pressure, tilt, roll, and even a second round tip on the back of the pen for "erasing."

    Not a flame. If Linux and GIMP cannot handle these (as well as the CMYK/halftoning/separation features needed by page printers), then the GIMP is sadly relegated to web banners, stock photography edits, and other simplistic work. ART needs an expressive tool set.

  • First, you might want to take him out of that box in the basement and get rid of the leather hood. I imagine the skin conditions attached to prolonged box-storage are pretty deplorable...
  • Don't get me wrong... Gimp is very cool. But- I't would be good if for future versions they concentrate on making it a little more l-user friendly. You know, maybe hiding away some of the advanced features unless you select a mode that gives you the world. It seems a bit overkill to do some simple tasks that I could do quickly in another application (sometimes). It's overall appearance is not bad, but it isn't great either. They should use gimp to generate some graphics to spruce up it's menu's and interface a little bit... IMNSHO.

  • Someone needs to merge that 16 bit branch into the main source tree. 8 bits really isn't enough for, say, visual effects work - but being stuck out on a limb is a bit annoying when the main development is happening somewhere else. Please merge it back in someone!
    --
  • I don't think JPEG or PNG supports CMYK. I don't think you need CMYK for web graphics or game graphics.
  • Right click the image then click a menu and click the "dotted line" at the top of a menu you want to "stick" on screen.
  • Was it on1ine photo 1ab [onlinephotolab.com]?
  • Well, there are a couple of books on the GIMP. A quick search on Amazon [amazon.com] turns up three. I learned most of the GIMP by scrounging the gallery however; there is some really neat artwork with pretty detailed descriptions of how it's done. The most awe inspiring trick I saw was to start out with a scanned-in pencil drawing -- I never made the mental connection that painting with a pencil is easier than painting with a mouse.

    It's got a very steep learning curve, but that is no different than Photoshop. Most of what you don't know (well, what I didn't know) was what operations I wanted to apply, in other words: what I wanted to achieve in the first place. It is hard to wrap my mind around graphics design.

    I would also expect that setting up a course in using the GIMP would be difficult because of this. Then again, I'm no course designer, so...

  • I've been using 1.23 since the day it came out, and it seems good enough to be a full release. If the final releases are as good as this one, the Gimp will start getting major attention in the "mainstream" news. (more than just the articles about the crazy Photoshop clone developed by those free software lunatics)

    I look forward to the day when schools start offering Gimp classes instead of Photoshop classes.

  • Implement photoshop plug-in compatibility and suddenly GIMP would have ten times as many features availible, from freeware on the net to extremely polished professional printshop stuff.

    Don't implement photoshop plug-ins and people who have invested in them (be it money or learning-curve time) will not move to GIMP, and GIMP development will be slowed as people waste their time re-inventing wheels that are freely availible as plug-ins, leaving less time to improve the fundamentals.

    It's so rare to get a useful and functioning plug-in standards for graphics. Use it, whatever the difficulty.

  • UI (menu structure) (Score:3)

    by mattdm ( 1931 ) on Monday June 19, 2000 @02:05PM (#991519) Homepage
    I don't mind the multiple windows so much, but the multi-level context menus drive me crazy. With photoshop, commonly used functions are in the same place every time -- I don't need to look, because my hand knows where to click. That doesn't work with the Gimp's UI.

    --

  • KDE integration. (Score:3)

    by Forge ( 2456 ) <kevinforge AT gmail DOT com> on Monday June 19, 2000 @01:46PM (#991520) Homepage Journal
    That's right. After that silliness with "Kimp" The KDE people hacked up an image manipulation tool of their own. It's called kImageShope and it integrates well with KDE and Koffice with that embedding and stuff. Needless to say it looks more like Photoshpe than it dose like the Gimp.

    The really cool thing about it is that it will work with Gimp plugins without them being modified in any way. For those new to image manipulation on Linux most of the Gimp's power is in those awesome plugins.

    So yes. For all practical purposes the Gimp will soon have KDE integration with all the power that implies ( click image in KWord and edit it in place. yada yada )

  • Wavelet/Multiresolution Drawing Support (Score:3)

    by jetson123 ( 13128 ) on Monday June 19, 2000 @02:55PM (#991521)
    With ever increasing image resolutions, I think the GIMP needs wavelet or multiresolution drawing support.

    That is, images are represented at multiple resolutions. When you edit it at low resolution (zoomed out), only the low resolution representation needs to be modified. When you zoom in and edit details, only a small part of the high resolution representation needs to be modified. Global color adjustements and many kinds of other global image processing operations can also be done very fast.

    This kind of representation would allow the GIMP to work fast for nearly arbitrarily large images and arbitrarily fine detail, since processing speed is determined by the part of the image that is actually displayed and being modified. It is also a good match to the upcoming JPEG2000 standard.

    But this kind of support needs to be built in from the ground up, since filters and tools need to be coded differently.

    A good introduction to the subject is the book "Wavelets for Computer Graphics" by Stollnitz, DeRose, and Salesin.

  • When will Gimp quit being a gimp? (Score:3)

    by Rader ( 40041 ) on Monday June 19, 2000 @02:30PM (#991522) Homepage
    I've used Photoshop for years. The newspaper my parents own bought it many many years ago, and thus I've had my "free" copy to use since then. I continue to buy the latest upgrade for them, to get the key features we need.

    However, this last "upgrade" was only 5.5 from 5.0 and had nothing new to offer (at least for us) In fact, the only really new thing to offer was another product they're "Kind-of" integrating, and won't actually be fully integrated till 6.0

    With the recent story [slashdot.org] Slashdot ran about the Insider Mac web site running "secret" information about the new 6.0 release, there were a LOT of posts saying that 6.0 wouldn't have many new features either. Even saying that the only reason Adobe was so upset about the leak was that people would find out how featureless (and waste of money) the next release would be.

    And with Adobe's marketing buzzwords like "Best Release Ever".... wait... I'm sorry. I just can't be as corny as them, so I won't list any more. --But they were good!!!!

    So with Adobe running out of steam for interesting ideas... When will GIMP catch up? Can Gimp catch up? How many people are working on this thing. Is it just the original creator??? Will they have to hire a larger team when they hit the "releasable" 2.0?

    I hear a lot of people saying the Photoshop will rule because of CMYK. However, I hear more and more people saying that the RGB is all they need. And it's true, if all you need is WEB-output!! And obviously web graphics are important now compared to the 80's when there was no such thing.

    One last thing to point out. I'm amazed at what these graphic tools can do. But what is more amazing is that it takes 15,000 apes at Microsoft to release maggot feces (read: buggy shit), but yet it only takes Adobe an extremely small workforce. Adobe is practically at the TOP of the "Net-Income-Per-Number-Of-Employees" list.

    So... If Adobe can push this kind of software with their "small" gropu, I'm sure Gimp can too. I can tell you what... that Adobe will never make a Linux version! If they had their way, it'd be MAC only. It still comes out Mac-platform first. (Not as bad as it used to be, though)

    Rader

  • Re:A Sad Gimp Story (Score:3)

    by BigSven ( 57510 ) on Monday June 19, 2000 @03:01PM (#991523) Homepage
    Anyway, I sure would like to see multibyte support in the Gimp someday.

    GIMP FreeType, our freetype plug-in is on its best way to support multibyte fonts.

  • I know this isn't exactly on topic... (Score:3)

    by MaximumBob ( 97339 ) on Monday June 19, 2000 @02:46PM (#991524)
    ...but geez, that icon is scary. I was ok until I saw the eyes move. I actually jumped. Does it have to be animated?

  • Re:How to Fix the GIMP User Interface (Score:3)

    by -Harlequin- ( 169395 ) on Monday June 19, 2000 @05:54PM (#991525)
    >This is how to fix the UI for the GIMP.

    Yep, that would go a long way towards fixing it. However we are up against something bigger here. As an artist (specialising in computer work) it is becoming painfully obvious that the entire open source movement is still largely "by techies, for techies". And as long as this remains the case, any software that requires expertise outside that narrow range (such as graphics apps, games, 3d animation, possibly even word processing) is crippled by the nature of the open source movement.

    A while back, I had the time to contribute to the movement. I couldn't find any projects that were looking for such help. Perhaps this was because you had to be a techie to know where to look to find such a project, or perhaps it was because many techies simply don't realise how crucial the non-programming parts are if you're trying to make a fully functional product that can compare to normal commercial software.

    Hell, remember when /. reported that id Software had fired one of their developers, Paul Steed, allegely out of spite? I saw _multiple_ replies stating "Uh - Paul Steed isn't a developer, he does 3d models and art". What?!?
    If this thinking is symptomatic of a significant portion of linux developers, linux ain't going anywhere beyond servers and enthusiest machines anytime soon. Windows shall forever reign supreme.

    Programming is only one part of good software, and now that everyone is an artist (because they can operate GIMP or PS), everyone is a designer (because they can write html), everyone is a UI developer (because they can write code), we're going to have to deal with the fact that these beliefs are simply false. Flawless html doesn't make flawless design, flawless programming doesn't make a useful UI, flawless pixel manupulation doesn't ensure flawless communication of a concept. These are different skills, and the sooner this is widely understood and accomodated, the sooner open source becomes a genuine alternative.

  • GIMP v. Photoshop (Score:3)

    by cvd6262 ( 180823 ) on Monday June 19, 2000 @01:54PM (#991526)
    Other people have pointed out that as good as GIMP gets, it's not Photoshop. The good thing about Photoshop is that you don't have to be a comp.sci major to use it, but the great thing about photoshop is that if you understand how it works, you can do some amazing things. GIMP just isn't there yet.

    CMYK support would be a big thing. Asides from it's print advantages (most printing is not done RGB), CMYK allows for some effective touch up. Took the pictures in a photosensitive area of a clean room (you know, the yellow light)? Convert the image to CMYK, chuck the yellow, adjust the cyan and, poof! No more yellow. The image looks normal.

    However many features you give and/or take with GIMP, the reason I still will use Photoshop is just how it feels. It's sad, but GIMP may never get to that point due to the platform it's being developed on. I started using Photoshop seven years ago, and I use GIMP to play around on my Linux box, but I just don't see the two converging. Maybe that's a good thing.

  • How to Fix the GIMP User Interface (Score:3)

    by LionKimbro ( 200000 ) on Monday June 19, 2000 @03:20PM (#991527) Homepage

    I am disheartened to read that attention is not being paid to the GIMP UI.

    The GIMP has 1st class, state of the art capabilities, but it's user interface is terrible.

    Believe me; I Love the GIMP, but I just had my first fight ever with my girlfriend of 3-months; it started when she said, "I don't ever use the GIMP; I will only use Corel Photoworks (or whatever it was). The $500 I paid for it was worth every penny." After sitting down with my girlfriend for about an hour with the GIMP, I had to agree that the UI was bad.

    Unfortunately, I cannot "just go into the GIMP source code and fix it", the problem is larger than one lone volunteer can solve.

    The UI is a traditional Achilles Heel of Free and Open Source Software. Fortunately, there is a traditional solution to the problem as well, namely embedded scripting languages and extensive customizability.

    The GIMP will take off when the UI is fully customizable; Making the UI maximally customizable should become the GIMPs next great goal.

    1. Artists are craftsmen and want to be able to get their tools just right. They want their particular brush, their particular colours, their particular keystrokes, their particular default layout, just right. I don't know how many times I have heard artists say, "I wish it was just organized like this," or, "Why did they put that there?"
    2. A subset of artists will have coding abilities, and the time to work with the GIMP. After the programmers have made it easy for the artists to easily customize things, the artists will be able to customize the work environment to be usable.
    3. The artists will customize the GIMP in many ways and upload their customizations to themes.org. The good customizations will float to the top, the bad ones will sink to the bottom. Great customizations will be included with the GIMP.

    This is how to fix the UI for the GIMP.

    This is how ALL OpenSource UIs have been fixed- By giving the users an easy way to customize their environment.

    Okay, that's enough for now... =^_^= . o O ( Phew! )

  • A Sad Gimp Story (Score:4)

    by Kismet ( 13199 ) <pmccombs AT acm DOT org> on Monday June 19, 2000 @02:45PM (#991528) Homepage
    I recently started to work at a large International Software development firm. Our client was developing a business-to-business procurement solution that was to be global in every aspect. The program would be web-enabled.

    Development was to be Microsoft-centric. Coming from a strong Unix background, I decided to use whatever familiar Unix tools I could to get the job done in record time. Central to my strategy was Perl-Fu for Gimp. I would use it to automate the localization of the images in the product.

    It worked fabulously until Korean came along. I abruptly learned that the Gimp is incapable of rendering multibyte fonts. I suppose I should have checked that feature before I started, but the point is that I ended up having the company buy a copy of Macromedia Fireworks and scripting the enxtensions in JavaScript on Microsoft. What a pity.

    Anyway, I sure would like to see multibyte support in the Gimp someday.

  • CMYK Color (Score:4)

    by linuxonceleron ( 87032 ) on Monday June 19, 2000 @01:37PM (#991529) Homepage
    To keep people from saying "Photoshop rules until GIMP has good press-ready CMYK" I think that the GIMP should be able to do CMYK color conversions. Also is there any way to interface the GIMP's plugins/script-fu to a web server to use as CGIs? On the fly generated images would be mucho cool.

  • Re:CMYK Color (Score:4)

    by Pinball Wizard ( 161942 ) on Monday June 19, 2000 @03:43PM (#991530) Homepage Journal
    a couple of the other replies mentioned net-fu.

    There is a great book you should pick up, Programming Web Graphics with Perl and GNU software, from O'reilly. This goes into detail about scripting the Gimp with Perl. You also learn about ImageMagick and other image scripting utilities.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close