GIMP 2.8, any caveats?

I have been running GIMP 2.8 on Windows, but still 2.6 on Linux. The SaveAs => Export change is bothering me, and the easiest solution is probably to upgrade by PPA on Linux.

Any reason why GIMP 2.8 and this man should not be united on the Linux desktop?

Is GIMP 2.8 slower than 2.6, or more of a memory hog?

I have not noticed much difference, nor am I relying on any new features. Thanks.

With the recent 2.8.2 update, there's little I would say a problem with GIMP. I do run it in Windows though.

--



Psalm 109:8
http://www.biblegateway.com/passage/?search=Psalm%20109:8&version=KJV

Runs great on Linux. No issues on Ubuntu 12.04LTS. Running Gimp 2.8.2, and various plugins. GMIC, etc.... Also run 2.8.2 on Windows 7 Pro, no issues. Performance is good.

lylejk said:

With the recent 2.8.2 update, there's little I would say a problem with GIMP. I do run it in Windows though.

Click to expand...

I would say there's little right with it, especially on Windows. Note that I am using 2.8.2. I spent hours discovering these and finding workarounds. Instead of messing with Hubble Telescope data and blending images I spent at least 2.5 hours on this crud! Note that I'm no computer newbie. I work as a computer programmer, have an IT degree, and play with all kinds of software in what free time I have.

I'm guessing the only reason others don't have issues is that they never open RAW files or do anything more than play with curves/levels, saturation and built in sharpening filters. Firefox and GIMP are 2 open source projects that were so good when I think of what the developers have done to them I almost want to cry.

Here's what I found in a handful of hours of use.

• GEGL library for transformations etc are a joke! They are slow and give less control than the old version of the function they replace. Rotate tool is a prime example. You use to be able to set an arbitrary angle of rotation. Now it will only rotate in certain increments, rounding to the nearest one it will actually do if you move off the dialog. Then it takes a REALLY long time compared to GIMP 2.6 to actually perform the rotation.

• The installer doesn't let you pick 32 or 64 bit. It forces 64 bit if you're on a 64 bit system (which I'm told breaks some plugins - like PSPI - the plugin that lets you run some Photoshop plugins within GIMP) . I HATE it when choice is removed from the user.

• UFRAW requires a workaround to install. This is in part due to the UFRAW Author's hate of Windows and refusal to support Windows. However the GIMP installer forcing the 64 bit version without giving the user a choice contributes. The workaround: You have to install in the same directory as GIMP on a 64 bit system. Okay fair enough. Except that if you actually install GIMP then install UFRAW it breaks the ability to open TIFF files giving an error. What happens is that if you try to open a TIFF you get application errors from tiff-file-load.exe.

The workaround: If you use portableapps installer to install GIMP as a portable application then install UFRAW over the top this does not happen. Both RAW and TIF seem to work properly.

There is a workaround in the link below for the installed version involving replacing libtiff-3.dll but I didn't get it to work for me the one time I try. I don't have any more time to spend hand installing DLLs to find out what went wrongm and by that point I wanted to throw something at the computer.

• GIMP GAP - the animation addon for GIMP is reported to not be fully working. Who knows if or when it will be updated.

• I've experienced no crashes. Others have experienced a lot of them. Haven't looked into this.

If you want to avoid a lot of this nonsense there is a package - GIMP Photocomix - that is MUCH larger than GIMP that is built on top of it. I haven't tested it much so I can't vouch for stability and I'm sure it inherits some of GIMP 2.8's issues (like rotation example above). It appears to include a mass of plugins including GIMP GAP and a few of the better GIMP plugins. But it seems to be developed by one guy and who knows how well it will be supported. There is a 2.8.2 based release candidate available. It reminds me a little bit of the now defunct GIMPShop in that it seems to do good things but may not gain much traction. I don't know the authors of these pieces of software, nor am I associated in any way. I've downloaded GIMP Photocomix but am reluctant to become dependent on it. Therefore I am now using two slightly customised portable versions of GIMP with a few plugins that I know well and use like G'MIC added - one of 2.6 and one of 2.8.2.

I find myself gravitating to launching 2.6 because I don't like migraines. I spent 2 hours on installing 2.8.2 for what should have been a 10 minute job blending images very roughly. In contrast GIMP 2.6 was hassle free to use - install what you need and it worked and worked well. I ended up using 2.6.

Here are some references
http://gimpchat.com/viewtopic.php?f=8&t=4266
http://www.gimpusers.com/forums/gimp-user/14804-gimp-2-8-2-windows-64-bit

--
Sammy.

My forum postings reflect my own opinions and not those of my employer. I'm not employed in the photo business.

I'd suggest that if you work from RAW then use e.g. RawTherapee, which will send a conversion directly to GIMP if you tell it to.

I'm also irritated by the developer's decision to create GEGL, which is still only at version 0.2, for GIMP. I think it was a error of judgment falls into the category of needed like a hole in the head . It's not as if there weren't already a number of image processing libraries out there, for example ImageMagick, which are stable and complete.

They've now got three problems. First GEGL isn't even Alpha quality and I'm dubious it will be before GIMP 3.0. Second there's no clear documentation on how plug-in writers should work to avoid future problems, which is going to slow plug-in conversion. Third, there's now work on an OpenCL interface which means there are going to be three completing modes for writing plug-ins. Which one gets the mainline support ?

This is very much the same story as GIMP has always suffered from - they want to do everything themselves rather than using what's already available and co-operating with other projects.

--
StephenG

I do not have the expertise, but someone needs to fork off 2.6 if that's salvagable. Or perhaps start from scratch. I'll keep using some version of GIMP but only because it's free and legal and doesn't cost anything.

They should have focused on 16 bit support, and gone to a single window interface long ago instead of wasting everyone's time and shipwrecking the project.

--
Sammy.

My forum postings reflect my own opinions and not those of my employer. I'm not employed in the photo business.

CAcreeks said:

Any reason why GIMP 2.8 and this man should not be united on the Linux desktop?

Click to expand...

I'm running 2.8.2 with UFRaw both on Win7 as well as my, much preferred, Linux system (64-bit PCLinuxOS) and I shoot RAW exclusively (14.6Mp K-5 PEFs)

I extended UFRaw with the LensFun library with updated lens profiles from the GIT repositories, as well as up-to-date camera color profiles from the RawStudio project.

Tons of plugins and scripts all working perfectly well and fast. My essentials include Liquid Rescale and Resynthesizer (Heal Selection) - both fairly heavy plugins that do a lot of processing. Also a staple is GMIC.

CAcreeks said:

Is GIMP 2.8 slower than 2.6, or more of a memory hog?

Click to expand...

Not that I noticed, quite the opposite actually although I'd be hard-pressed to quantify.

CAcreeks said:

I have not noticed much difference, nor am I relying on any new features. Thanks.

Click to expand...

If you, like many others, are bothered by the Save-versus-Export feature, there's even a script that covers that ( https://github.com/akkana/gimp-plugins/blob/master/save-export-clean.py )

The biggest feature for me is single-window mode but the tabbed files across the top also appeal to me very much. I think GIMP just got a whole lot better.

--
http://mike.bing-photography.com
http://www.flickriver.com/photos/newmikey/
Opensource: fresher, tastier and cheaper!

I used GIMP some years ago v2.6. Even then it was pretty outdated compared to PS 5. Almost a decade behind in terms of functionality and features.

I now use PS 6 and couldn't be happier. Still has some glitches but it's amazing what can be done with it. And it's all non destructive !!! SmartObjects are soooo cool.

Is PS expensive and overpriced ? Definitely. But it let me do things that were quite hard or even impossible to achieve with GIMP.

It's my believe that beyond a certain limit of complexity paid full time developers are required to create a high end product. Working for free in ones spare time is simply not enough.

What is most irritating about GIMP is that it was forked to support higher bit depths a long ways back ( Cinepaint - http://www.cinepaint.org/ ). The GIMP people went into a rather nasty "not invented here" mode and the two projects are essentially separate now.

The GIMP people won't even accept plug-ins that include #define CINEPAINT sections to make life easy for developers.

--
StephenG

I thought it was a dead open source project. Is it still active?
--
I'm so bright, my father calls me son.

Now that you've judged the quality of my typing, take a look at my photos. . .
http://www.jpgmag.com/people/glenbarrington/photos

sjgcit said:

It's not as if there weren't already a number of image processing libraries out there, for example ImageMagick, which are stable and complete.

Click to expand...

It's always the question if a GNU-licensed project like the GIMP can even make use of those libraries, if they are not published under GNU themselves. And if GIMP would choose to be non GNU-compliant, they could no longer be directly incorporated into the major linux distros, or in their software repositories.

remains the question why they didn't hold on to what they had, if that worked.

Have to admit I don't use GIMP for RAW processing (never have; no plans in the future either). GIMP's not for high bit depth editing yet, but GEGL promises to give GIMP that ability in 2.10; indeed the beta 2.9 has already started adding high bit depth abilities, but it's too new for me to even bother playing with yet (I'll wait for 2.9.5 or 2.9.7 then maybe I'll experiment). As for 2.8.2, yes, I've heard some complaints about the integration with other opensource projects to handle RAW. Also, I know there's been some fupahs with GEGL, but none of these features I use. If you need to process RAW or high bit depth images, then use another program. I strictly use GIMP for 8-bit image retouching (99.9% of what I do is retouching) mainly for eclectic effects and many here know. GIMP is more then apt enough for that and 2.8.2 64-bit has been rock solid not to mention I can run many PS filters in it or if need be call shellout and use a surrogate to call PS filters. Folks, it's not a commercial product like PS is; it is a fantastic open source program and gets better as it matures. If you are going to use open source programs, then learn the bells and whistles of those programs and learn the concept that there's more then one way to skin a cat. If you want perceived convenience, then purchase a program that meets those needs. I have no beef with PS (other then their new upgrade policy) and indeed do all my RAW processing (I admit I'm not a photog and only take my Leica out a few times a year to take a handful of captures that need RAW processing) since ACR is my crutch for that and hopefully my Leica VLUX1 will last many more years since I have no plans to upgrade CS5 (see my earlier quip).

In summary, don't worry; be happy.

--



Psalm 109:8
http://www.biblegateway.com/passage/?search=Psalm%20109:8&version=KJV

Cinepaint's most recent source file releases were dated April this year, so it's active.

I've not been able to compile it myself yet ( an issue with different build tools versions ).

--
StephenG

This obsession with rigid GNU compliance isn't really an objection in my view.

It's not in the least uncommon for distributions to include non-GNU licensed code. And just invoking a non-GNU library via an API does not invalidate a GNU license. There are OSI compliant libraries which could be used.

A linux distribution does not have to be completely GNU compliant, AFAIK.

--
StephenG

joey_B said:

sjgcit said:

It's not as if there weren't already a number of image processing libraries out there, for example ImageMagick, which are stable and complete.

Click to expand...

Click to expand...

"Complete" is the key word. Complete for what? ImageMagick is complete for what it does, but it does not do what the future holds for GIMP!

joey_B said:

It's always the question if a GNU-licensed project like the GIMP can even make use of those libraries, if they are not published under GNU themselves. And if GIMP would choose to be non GNU-compliant, they could no longer be directly incorporated into the major linux distros, or in their software repositories.

Click to expand...

As sjgcit has already pointed out it is not correct that Linux distributions need to be all GNU licensed code. Common examples which are not include the X Windowing system, the vim editor and everything else from UCB, browsers such as Seamonkey, etc.

Regardless, the ImageMagick code is in fact licensed with a GPL V3 compatible license, and can be linked into GNU projects without problems.

joey_B said:

remains the question why they didn't hold on to what they had, if that worked.

Click to expand...

There are a huge and important list of things which could never be done without moving to GEGL. The most obvious one that people get excited about is the ability to edit and save files at bit depths greater than 8. But the real advantage to GEGL is much greater and will eventually allow other advances.

The older GIMP model operated on image buffers, and edits were applied to the buffers in sequence. A series of undo buffers containing the differences allowed backing out of edits, but only in the same sequence they were entered. In GEGL an image is maintained as a graph of nodes, where each edit is a node; but nodes are not fixed in sequence as the graph can be output to a display or to a file in any sequence. When it is fully implemented GIMP will have non-destructive editing, and any edit will be modifiable, repositionable within the graph, or removable without changing other edits done later in sequence.

apaflo said:

There are a huge and important list of things which could never be done without moving to GEGL. The most obvious one that people get excited about is the ability to edit and save files at bit depths greater than 8. But the real advantage to GEGL is much greater and will eventually allow other advances.

Click to expand...

...

apaflo said:

The older GIMP model operated on image buffers, and edits were applied to the buffers in sequence. A series of undo buffers containing the differences allowed backing out of edits, but only in the same sequence they were entered. In GEGL an image is maintained as a graph of nodes, where each edit is a node; but nodes are not fixed in sequence as the graph can be output to a display or to a file in any sequence. When it is fully implemented GIMP will have non-destructive editing, and any edit will be modifiable, repositionable within the graph, or removable without changing other edits done later in sequence.

Click to expand...

...and at this rate by the time they have those features, they'll have burnt through the entire user base.

GEGL or something like it may have been needed to implement certain features. That is no excuse for such a poor execution of that plan or for producing code that is much slower, much more restrictive and much buggier. Done correctly, there is no inherent technical reason I'm aware of that rotation should only be allowed in certain increments or that the GEGL operation should be between 3 and 10 times slower than the buffer based approach.

--
Sammy.

My forum postings reflect my own opinions and not those of my employer. I'm not employed in the photo business.

Well, I had problems with the PPA keyring and our firewall on Ubuntu 8.04, so maybe I need to upgrade Ubuntu before GIMP. Might be easier to install GIMP 2.6 on Windows, given all that's been said in this thread.

newmikey said:

The biggest feature for me is single-window mode but the tabbed files across the top also appeal to me very much. I think GIMP just got a whole lot better.

Click to expand...

Single-window is one thing I disliked about Photoshop CS2 - I like arranging toolboxes - but chacun à son goût .

newmikey said:

If you, like many others, are bothered by the Save-versus-Export feature, there's even a script that covers that ( https://github.com/akkana/gimp-plugins/blob/master/save-export-clean.py )

Click to expand...

Thanks, that looks good.

Just downloaded Linux Mint 13 with Cinnamon desktop. It looks nice, but many settings do not work (for example: move panel to top of screen, highlight active window). However it was easy to download MATE and switch desktops. MATE is superb. I like the way it claims to be "non-intuitive and unattractive" (irony).

Wow! This is my favorite Linux since Ubuntu 8.04. Ubuntu 10.04 was fine but not a huge advance and lacked beautiful Heron background. I like the green colors of Mint after the desert-like colors of Ubuntu.

Robert Kovacs said:

Runs great on Linux. No issues on Ubuntu 12.04LTS. Running Gimp 2.8.2, and various plugins. GMIC, etc.... Also run 2.8.2 on Windows 7 Pro, no issues. Performance is good.

Click to expand...

Yes, 2.8.2 seems acceptable. I downloaded 2.6.12 on Windows XP so I get the same interface on Linux and Windows, but if I can switch everything to Linux Mint 13. I will re-install 2.8.2 on Windows. Thanks.

I have noticed a lot of new bugs, as well. Two functions that I was using frequently no longer work in Windows 10.

When I now go to View > Toggle External Preview it gets a temp file error message.

When I try using the Code Cleaner, it no longer works either.

I wonder what this is about. A new user responding to a 4 year old thread.

kweather9122 • New Member • Posts: 1

The thread ran from Sept. 6 to 12, 2012.

A potential future spammer account avoiding detection?..