Hacker News Reader

> so if you're doing work targeted at a computer screen, it probably doesn't matter anyway

Actually, it matters regardless of output device. With higher bit depths, less rounding errors accumulate over time as the image is processed, for example when effects are applied, yielding higher overall output quality.

Here is an example, although after many iterations quality loss can be much more dramatic than visible in that picture: http://www.photoshopessentials.com/essentials/16-bit/page-3....

Yes. It matters a great deal if you're trying to recover information from underexposed or nearly overexposed regions of an image. Adjusting the levels of an image is something photographers do all the time, and having 14bits per channel allows you to do it without producing a grainy-as-hell image. Throwing away almost half of the information on the initial import is unforgivable and relegates GIMP to being merely a toy.

Oh please stop the flame, this is ridiculous. Photoshop didn't support 16 bits before CS, in 2003. Did it prevent people to use it ? Would you say that all magazine covers were "child play" before then?

Not true. Photoshop has had support for 16 bits since at least version 3. What CS brought was full 16 bit support for all layer adjustments and painting features. Before that 16 bit was only supported by a subset of the available editing options.

Still though, the sniffy "merely a toy" is kind of over the top. Are automobiles merely toys because they don't have the range, passenger capacity and speed of a Boeing 747? How about motor scooters? And bicycles? The Gimp is not as good as Photoshop. Is it good enough for many uses? Sure.

Having an attitude of "It's good enough" is probably why GIMP has made such a small amount of progress in recent years.

That's not the kind of 'good enough' I meant. It's good enough for many things, not "so good that it doesn't need improvement". Anything can be improved, and doubtless the people who work on it know that.

Indeed. And having progress per se is what proprietary software like Photoshop has to do in order to sell more licenses. Why would you buy the most recent CS version if Photoshop 6 was certainly good enough?

The logic is different. GIMP does not have to evolve in order to survive. It's open and if you need it doing something it doesn't, you can hire a developer to do it. The fact nobody does it is because it's good enough for what it's used for.

+1, although, to be correct, economically "the fact nobody does it" means the cost is higher than the benefit. You could purchase a copy of photoshop for much cheaper than the cost of hiring a good developer for a week.

Open source economics are tricky.

> You could purchase a copy of photoshop for much cheaper than the cost of hiring a good developer for a week.

True. That's why pooling resources is such a good idea. If you need a feature that's missing from Photoshop, you can find other people who need that feature (or would like to have it) and pool resources to hire someone to do it in GIMP. If you have a company with 10 seats using Photoshop, it may start to become cheaper to hire a GIMP developer than providing all employees with a Photoshop license (and Adobe must have corporate licenses exactly to counter that reasoning)

Yes, this sort of thing makes it interesting (and tricky). For 'common features', buying commercial products is a good, and really simple way of pooling resources. You buy the product that has invested in the features you want. When you start talking about one-off types of things, or special, advanced features, open source can start to look a whole lot more competitive, especially since there is no monopoly on who is going to do the work.

>The fact nobody does it is because it's good enough for what it's used for.

And what it's used for isn't the listed things because it can't do them. Blub in a sense perhaps.

And the GIMP supports 16 bits for most operations, simply by enabling GEGL in the Color menu, therefore it is quite equivalent to old Photoshop in this regard.

> With higher bit depths, less rounding errors accumulate > over time as the image is processed,

This could also be solved by another photoshop feature, adjustment layers. Basically instead of applying a filter like levels to an image you make a levels layer that applies the levels affect to everything underneath it. The original data is untouched, and you can tweak the levels at any time.

I'm strictly a hobby user for photos I take, but without support either 16 bit colour or adjustment layers GIMP is not good enough for me. My solution is to use an older student version of photoshop I picked up cheaply; I don't need all features in the latest version.

No, that doesn't actually do anything to solve the underlying problem. Stacking five adjustment layers has the same accuracy problems as doing the same five operations sequentially. It may let you tweak them without roundtripping through further loss but the loss is already significant by that point.

Technically yes, but not at all in practice. Once you run 3 adjustments you generally want to tweak the first. Without adjustment layers you usually just run a fourth transformation.

Ye gods, can't you read until my third sentence between smashing the reply button and "correcting" me?

Plus selectively painting the mask of an adjustment layer is useful as well

Er, theoretically, no. I don't know what Photoshop's implementation is, but computing the cumulative effect of the adjustment layers will result in less error than applying them in sequence. That's part of why GEGL is being written.

[Edit] I'm referring to the fact that fixed-precision arithmetic loses (well, stochastically speaking) precision with each operation. You can condense the layer effects and apply the 8-bit operation only once to minimize error. This is especially true if your layer combinator works at a higher level of precision than the layer operation itself.

[Edit 2] As an example, consider the layer operations "Multiply each channel by 0.5" and "Multiply each channel by 2." Applying these layers separately to a value loses something like a half bit of precision (more for smaller values, less for larger ones). A layer combinator could multiple 0.5 by 2 and yield ~1.0 (in general, subject to the floating point precision which is generally finer than the image precision). That results in a smaller error.

I think you may be secretly sneaking a step whereby the adjustment layers all run with more bits then only collapse back out to 8-bit at the end to get their higher quality. If you've fixed your code to work with the adjustment layers, you might as well fix it to work that way in general, which I think what GEGL is . It's still not the "adjustment layers" that are fixing anything, it's the fact that you're actually retaining the bits. Pure 8-bit adjustment layers will still look bad, and 12/14/16/8+-bit normal layers will look much better with and without adjustment layers. You can't escape from the fact that computing with too few bits necessarily entails information loss.

>> almost all monitors display 32-bit color anyway

Actually, I was surprised to find out that this is not the case.

"The inexpensive twisted nematic display is the most common consumer display type."

"Also, most TN panels represent colors using only 6 bits per RGB color, or 18 bit in total, and are unable to display the 16.7 million color shades (24-bit truecolor) that are available from graphics cards."

http://en.wikipedia.org/wiki/TFT_LCD#Twisted_nematic_.28TN.2...

Any idea how most modern CRTs handle color? I'm not seeing anything specific on Wikipedia's CRT page...

CRTs will show what the RAMDAC on the video card feeds them. They shouldn't have limitations like this.

Even if you don't care about the GIMP/Photoshop comparison, make sure to check it out if you're a GIMP user. It has a bunch of little tips as to how to get photo and retouching done with GIMP; I've used GIMP for years now, but had never realised what Selective Gaussian Blur was really useful for.

(These sorts of tutorials are very thin on the ground on the GIMP side, and this provides some real examples of how to more-or-less pull off the effects Photoshop tutorials tend to talk about.)

>never realised what Selective Gaussian Blur was really useful for

This is probably the filter I use most - basically it smooths colours that are close positionally and colourwise to avoid graininess. A good way to clean up images quickly though it can look unnatural if done too much.

I often use a little SGB and then a little Unsharp Mask when touching up images for low-res or online output.

I'm not professionally trained but do use this for commercial purposes and have for some time.

> Ars Technica did an excellent review of GIMP 2.6 about a year ago.

From the article, seems like it was 2 years ago: "Last updated January 13, 2009". Might seem like an insignificant detail, but 2 years is an eternity in OSS. Are you sure things haven't changed significantly since that review?

Agh. Here's me still thinking it's still 2010.

Yeah, unfortunately things really haven't changed since the review: we're still on the same major version (2.6) that we were when the review was published. (Hence the comment at the end about development seeming to have slowed a ton.)

Yes.

I used GIMP exclusively between 1999 and about 2009. There was always something coming in the next version that would fix GIMP. Color profiling, single window, better text tools, etc. They never did. GIMP doesn't even bother subscribing to GNOME's HIG. It's cast adrift in the world of Linux, and after a decade of using it I'm now happily on Pixelmator on OS X.

As far as I know (and I've lurking on the gimp developer list for 10+ years), GIMP has never been a GNOME application. So, from that point of view, there's no particular reason to expect it to conform to GNOME's human-interface guidelines, is there?

It uses the same crappy GTK file mgt widget design philosophy as GNOME.

http://en.wikipedia.org/wiki/GTK%2B GTK is the GIMP toolkit, and GTK is run by the GNOME foundation. There's quite a bit of relationship between GTK/GIMP/GNOME, even if it may be mostly historical these days.

I've always considered GIMP to be a GNOME app, and most people I know have.

When the GNOME project was founded, they looked around for a widget toolkit, and found Gtk+, that was created for GIMP at that point.

> There's no particular reason to expect it to conform to GNOME's human-interface guidelines, is there?

How about 'not being weird?' Asides from the already mentioned historic background, GNOME is the most popular OSS Unix desktop.

Thanks for the Pixelmator reference. I've been a gimp user since its early days, but I can do without the irritants.

Actually most monitors are 18-24 bits. Tons of cheap TN panels are actually 6 bits with dithering to emulate a 24 bit panel. There are 10 bit and extended gamut panels, however.