How does GIMP compare to Photoshop?

[Sonic4Spuds]

Just out of curiosity I decided to do some calculations about 8 bit vs 16 bit, and what I discovered surprised me.

A standard 8 bit image stores 8 bits for each of the either three or four channels. As only three of the possible four channels are useful for photography I will discuss only the R,G, and B channels. 8 bits gives you 256 possible values for each channel. Now most of you are probably aware of this, but using the three channels which cameras can capture this gives you 16,777,216 or over 16.5 million possible unique colors. If you add the alpha channel this number rises to 4,294,967,296 or over 4 billion colors.

If you are talking 16 bit per channel you have 65,536 values per channel. For a photographer this gives you 281,474,976,710,656 or more than 281 trillion possible colors (assuming there are any cameras that can capture true 16 bit color). If you add the alpha channel you can store 18,446,744,073,709,551,616 values. I'm not quite sure what the name of this number is, but it is quite large enough for anything.

I personally don't know how many color values a camera is able to capture, but I don't think that it comes even close to the possible values 16 bit color is able to store.

-Sonic

[Donald]

A standard 8 bit image stores 8 bits for each of the either three or four channels. As only three of the possible four channels are useful for photography I will discuss only the R,G, and B channels. 8 bits gives you 256 possible values for each channel. Now most of you are probably aware of this, but using the three channels which cameras can capture this gives you 16,777,216 or over 16.5 million possible unique colors. If you add the alpha channel this number rises to 4,294,967,296 or over 4 billion colors.

If you are talking 16 bit per channel you have 65,536 values per channel. For a photographer this gives you 281,474,976,710,656 or more than 281 trillion possible colors (assuming there are any cameras that can capture true 16 bit color). If you add the alpha channel you can store 18,446,744,073,709,551,616 values. I'm not quite sure what the name of this number is, but it is quite large enough for anything.

That's a lot of colours. And if you're colour blind like me, it could drive you stir crazy! (or not, if most of them all look the same anyway!)

[revi]

Just out of curiosity I decided to do some calculations about 8 bit vs 16 bit, and what I discovered surprised me.

A standard 8 bit image stores 8 bits for each of the either three or four channels. As only three of the possible four channels are useful for photography I will discuss only the R,G, and B channels. 8 bits gives you 256 possible values for each channel. Now most of you are probably aware of this, but using the three channels which cameras can capture this gives you 16,777,216 or over 16.5 million possible unique colors. If you add the alpha channel this number rises to 4,294,967,296 or over 4 billion colors.

If you are talking 16 bit per channel you have 65,536 values per channel. For a photographer this gives you 281,474,976,710,656 or more than 281 trillion possible colors (assuming there are any cameras that can capture true 16 bit color). If you add the alpha channel you can store 18,446,744,073,709,551,616 values. I'm not quite sure what the name of this number is, but it is quite large enough for anything.

I think there's a slight misunderstanding: taking the alpha channel into account does NOT increase the number of colours you can encode (note: colours, not values): alpha channel adds transparency, so you'll mix the colour in one layer with whatever is underneath, and the result must be expressed in 8 or 16 bit without alpha channel (sooner or later). That said, none here ever disputed that 8 bits/channel was enough for display...

I personally don't know how many color values a camera is able to capture, but I don't think that it comes even close to the possible values 16 bit color is able to store.

Camera data are stored in 12 or 14 bits, and the value of using 14 bits is I think still being discussed (not only a question of camera construction, but also of physics imposing hard limits, aka noise). So currently, most cameras are able to encode up to (2^12)^3 or 68 719 476 736 values/colours.

A few things to keep in mind:
- in all cases, we work from black (no light) to white (all channels saturated), those possible values get mapped on a certain range (using 8, 12, 16 bits). As we have to do some interpolations to get RGB pixels, 16 bits/channel allows to minimise information loss in this step.
- as said, we always need to end up with 8 bits/channel, and that is enough for display on any known medium.
So the reason for using 16-bit in processing is NOT the extra number of colours that can be encoded, but to limit loss of information while processing.

To get back on subject (), I use the Gimp, but it seems that PS has some possibilities that make it easier to modify corrections you applied (adjustment layers?). That might be an advantage for those who do a lot of complicated adjustments over multiple layer groups (and might make life a lot easier for the ones with simpler images). As you won't find many using both the GIMP and PS, getting a good somparison between the two seems difficult

Remco

P.S. 12-bits/channel would probably work as well as 16-bits, if our computers had 12-bit words... the reason we have the choice between 8 or 16 bits in post-processing is purely dictated by the CPUs we use, which are designed to work with values over 8, 16, 32, 64, ... bits. Cameras use custom chips, so they have a free choice of bit depth (except for the final storage, which must be 8-bit based for compatibility with other equipment)

[Sonic4Spuds]

Remco,

Thanks for the info about the bit depth of camera sensors.

As to the alpha channel, I should have thought for a second before doing the calculations for it. I have been thinking that it may be useful to store something such as luminance in for archival image storage.

As to using both I have used both, though not PS on a regular basis.

-Sonic

[sleist]

I've been dual booting Windows and Slackware Linux for the past 8 or 9 years. I like GIMP, but I was not coming at it from the perspective of a long time Photoshop user (I've only been serious about photography for a little over a year). Those used to Photoshop have a difficult time with GIMP for a variety of reasons. The multi-window layout is bad enough, but the naming convention and layout of commonly used photographic tools is different enough to drive one nuts at first. Many don't commit to the learning curve and run screaming from the building before giving GIMP the chance it deserves. I hit the 8 bit limit in both GIMP and Elements, but I seem to be OK working with 8 bit TIFs.

One tool I love in Linux (if you go that route) is the KDE application digiKam. There is a Windows port for the 1.7.0 version, but it's very buggy so I don't recommend it on Windows other than to install for a peek at the interface. I would call it a Lightroom clone that uses your own directory structure instead of the library system. http://www.digikam.org/ I find the digiKam interface more intuitive than Elements, but I think it's more a case of the familiar winning out over the unfamiliar.

I have moved to Windows for most of my workflow due to preferring ViewNX and soon Capture NX2 for RAW processing, but I do bounce between operating systems because I just like doing some thing more in certain programs. As if my workflow wasn't schizophrenic enough

I find GIMP is much faster when running in Linux by the way.

[revi]

Another Digikam user

I like the program (and use it for storing/classifying my photos and for 90+% of my editing), but
1- they seem to have trouble to get a decent windows installer and
2- both 1.7.0 and 1.8.0 have nasty bugs in the RAW developer (1.7.0 drops metadata, and 1.8.0 has big issues with post-processing ); there is a 1.9.0 version that has both corrected, but I haven't seen a compiled version so far (and compiling that under windows is not for the faint of heart)

So, either wait a week or two for the 1.9.0, or 3 months for version 2.0 (which is supposed to have a lot of new functions, we'll see what they are worth)

To get back to the GIMP, note that it reads 16-bit formats quite well, and that it can do treatments in floating point.
As for it running faster under Linux, doesn't everything?

[sleist]

Hey Remco! Nice to see another Linux photog. I did notice some bugginess in the last 2 versions, but I've just about given up on RAW conversion in Linux so my issues were different. I tried UFRaw as well as the RAW converter in digiKam and was just not satisfied or confident in the results. My work flow was to transfer and edit/cull using Transfer NX and View NX2, convert to 8 bit TIFF (all in Windows), then switch to Linux and use digikam, showfoto, GIMP, then save as JPG and use kipi-plugins for uploads to SmugMug. I too am looking forward to the 2.0 version. I'm really hoping that they fix the integration with later versions of the lensfun library. Very simple an effective lens correction, but a bit dated when stuck at version 2.3

Well I fear I'm dangerously close to hijacking this thread to I will return y'all to the regularly scheduled discussion.